From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 02:47:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 883909B0 for ; Sun, 28 Sep 2014 02:47:36 +0000 (UTC) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56E2B295 for ; Sun, 28 Sep 2014 02:47:35 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id l13so8375iga.5 for ; Sat, 27 Sep 2014 19:47:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=nddP13lGt6OHcDXorVZ8MRr7wD3fXnvg5bmIslkXtQc=; b=fK+DwWs4AzF6onC3ndSrSEjBh06divEKstWrakDu1gHxOfy2hPnl5v5Q8+ZnLfzOAp ImId/qrAdngQdTms7fC69m9unfmupTjSj7AhzxoLfUZ8rOpTCFUWm8WQjOJa9LcfuOBX 3+MBPHzHaAqyxFMliNF9AiT65hCzahpJ4rIn77U41SprnujkJ+fv/i2jk7qWRmILD/C+ 3Bw74/9tHGK8zgkpvhzQ5oLudbdiTIFbLoVApNp154eE6/9l4jFP3i3R1szgH32ze/ga Od0WjWCkQpU9jeln6WEAgQcUjmNKthVT5Mg5lHJtrEvoZ3uu/GfXoz0r4mrywI/wzqO4 Y0pQ== X-Gm-Message-State: ALoCoQkCHesC1EjZDJ6AKB3WmWK6OPgbqugIl9wAuKlANUzqggdjiWyJvVStkV6MlxpYHCdrGVqI MIME-Version: 1.0 X-Received: by 10.50.56.42 with SMTP id x10mr8169246igp.1.1411872449221; Sat, 27 Sep 2014 19:47:29 -0700 (PDT) Received: by 10.64.13.33 with HTTP; Sat, 27 Sep 2014 19:47:29 -0700 (PDT) Date: Sat, 27 Sep 2014 20:47:29 -0600 Message-ID: Subject: SOEKRIS kernel config From: Tom Everett To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=089e01538746ce17f40504172b37 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 02:47:36 -0000 --089e01538746ce17f40504172b37 Content-Type: text/plain; charset=UTF-8 I see there is no SOEKRIS config on the tree, here https://svnweb.freebsd.org/base/head/sys/i386/conf/ I have attached one for addition to the tree. -- A better world shall emerge based on faith and understanding - Douglas MacArthur --089e01538746ce17f40504172b37 Content-Type: text/plain; charset=US-ASCII; name="SOEKRIS.txt" Content-Disposition: attachment; filename="SOEKRIS.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i0lsecl40 IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2kzODYKIwojIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZmlsZSwgcGxlYXNlIHJl YWQgdGhlIGNvbmZpZyg1KSBtYW51YWwgcGFnZSwKIyBhbmQvb3IgdGhlIGhhbmRib29rIHNlY3Rp b24gb24gS2VybmVsIENvbmZpZ3VyYXRpb24gRmlsZXM6CiMKIyAgICBodHRwOi8vd3d3LkZyZWVC U0Qub3JnL2RvYy9lbl9VUy5JU084ODU5LTEvYm9va3MvaGFuZGJvb2sva2VybmVsY29uZmlnLWNv bmZpZy5odG1sCiMKIyBUaGUgaGFuZGJvb2sgaXMgYWxzbyBhdmFpbGFibGUgbG9jYWxseSBpbiAv dXNyL3NoYXJlL2RvYy9oYW5kYm9vawojIGlmIHlvdSd2ZSBpbnN0YWxsZWQgdGhlIGRvYyBkaXN0 cmlidXRpb24sIG90aGVyd2lzZSBhbHdheXMgc2VlIHRoZQojIEZyZWVCU0QgV29ybGQgV2lkZSBX ZWIgc2VydmVyIChodHRwOi8vd3d3LkZyZWVCU0Qub3JnLykgZm9yIHRoZQojIGxhdGVzdCBpbmZv cm1hdGlvbi4KIwojIEFuIGV4aGF1c3RpdmUgbGlzdCBvZiBvcHRpb25zIGFuZCBtb3JlIGRldGFp bGVkIGV4cGxhbmF0aW9ucyBvZiB0aGUKIyBkZXZpY2UgbGluZXMgaXMgYWxzbyBwcmVzZW50IGlu IHRoZSAuLi8uLi9jb25mL05PVEVTIGFuZCBOT1RFUyBmaWxlcy4KIyBJZiB5b3UgYXJlIGluIGRv dWJ0IGFzIHRvIHRoZSBwdXJwb3NlIG9yIG5lY2Vzc2l0eSBvZiBhIGxpbmUsIGNoZWNrIGZpcnN0 CiMgaW4gTk9URVMuCiMKIyAkRnJlZUJTRDogaGVhZC9zeXMvaTM4Ni9jb25mL0dFTkVSSUMgMjcx MTM3IDIwMTQtMDktMDQgMjE6MDY6MzNaIG1hcmtqICQKCmNwdQkJSTQ4Nl9DUFUKY3B1CQlJNTg2 X0NQVQpjcHUJCUk2ODZfQ1BVCmlkZW50CQlTT0VLUklTCgptYWtlb3B0aW9ucwlERUJVRz0tZwkJ IyBCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVidWcgc3ltYm9scwptYWtlb3B0aW9ucwlXSVRI X0NURj0xCQkjIFJ1biBjdGZjb252ZXJ0KDEpIGZvciBEVHJhY2Ugc3VwcG9ydAoKb3B0aW9ucyAJ U0NIRURfVUxFCQkjIFVMRSBzY2hlZHVsZXIKb3B0aW9ucyAJUFJFRU1QVElPTgkJIyBFbmFibGUg a2VybmVsIHRocmVhZCBwcmVlbXB0aW9uCm9wdGlvbnMgCUlORVQJCQkjIEludGVyTkVUd29ya2lu ZwpvcHRpb25zIAlJTkVUNgkJCSMgSVB2NiBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMKb3B0aW9u cyAJVENQX09GRkxPQUQJCSMgVENQIG9mZmxvYWQKb3B0aW9ucyAJU0NUUAkJCSMgU3RyZWFtIENv bnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29sCm9wdGlvbnMgCUZGUwkJCSMgQmVya2VsZXkgRmFz dCBGaWxlc3lzdGVtCm9wdGlvbnMgCVNPRlRVUERBVEVTCQkjIEVuYWJsZSBGRlMgc29mdCB1cGRh dGVzIHN1cHBvcnQKb3B0aW9ucyAJVUZTX0FDTAkJCSMgU3VwcG9ydCBmb3IgYWNjZXNzIGNvbnRy b2wgbGlzdHMKb3B0aW9ucyAJVUZTX0RJUkhBU0gJCSMgSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBi aWcgZGlyZWN0b3JpZXMKb3B0aW9ucyAJVUZTX0dKT1VSTkFMCQkjIEVuYWJsZSBnam91cm5hbC1i YXNlZCBVRlMgam91cm5hbGluZwpvcHRpb25zIAlRVU9UQQkJCSMgRW5hYmxlIGRpc2sgcXVvdGFz IGZvciBVRlMKb3B0aW9ucyAJTURfUk9PVAkJCSMgTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBkZXZp Y2UKb3B0aW9ucyAJTkZTQ0wJCQkjIE5ldyBOZXR3b3JrIEZpbGVzeXN0ZW0gQ2xpZW50Cm9wdGlv bnMgCU5GU0QJCQkjIE5ldyBOZXR3b3JrIEZpbGVzeXN0ZW0gU2VydmVyCm9wdGlvbnMgCU5GU0xP Q0tECQkjIE5ldHdvcmsgTG9jayBNYW5hZ2VyCm9wdGlvbnMgCU5GU19ST09UCQkjIE5GUyB1c2Fi bGUgYXMgLywgcmVxdWlyZXMgTkZTQ0wKb3B0aW9ucyAJTVNET1NGUwkJCSMgTVNET1MgRmlsZXN5 c3RlbQpvcHRpb25zIAlDRDk2NjAJCQkjIElTTyA5NjYwIEZpbGVzeXN0ZW0Kb3B0aW9ucyAJUFJP Q0ZTCQkJIyBQcm9jZXNzIGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBTRVVET0ZTKQpvcHRpb25zIAlQ U0VVRE9GUwkJIyBQc2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsKb3B0aW9ucyAJR0VPTV9QQVJU X0dQVAkJIyBHVUlEIFBhcnRpdGlvbiBUYWJsZXMuCm9wdGlvbnMgCUdFT01fUkFJRAkJIyBTb2Z0 IFJBSUQgZnVuY3Rpb25hbGl0eS4Kb3B0aW9ucyAJR0VPTV9MQUJFTAkJIyBQcm92aWRlcyBsYWJl bGl6YXRpb24Kb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q0CQkjIENvbXBhdGlibGUgd2l0aCBGcmVl QlNENApvcHRpb25zIAlDT01QQVRfRlJFRUJTRDUJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q1 Cm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNENgkJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDYKb3B0 aW9ucyAJQ09NUEFUX0ZSRUVCU0Q3CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNENwpvcHRpb25z IAlTQ1NJX0RFTEFZPTUwMDAJCSMgRGVsYXkgKGluIG1zKSBiZWZvcmUgcHJvYmluZyBTQ1NJCm9w dGlvbnMgCUtUUkFDRQkJCSMga3RyYWNlKDEpIHN1cHBvcnQKb3B0aW9ucyAJU1RBQ0sJCQkjIHN0 YWNrKDkpIHN1cHBvcnQKb3B0aW9ucyAJU1lTVlNITQkJCSMgU1lTVi1zdHlsZSBzaGFyZWQgbWVt b3J5Cm9wdGlvbnMgCVNZU1ZNU0cJCQkjIFNZU1Ytc3R5bGUgbWVzc2FnZSBxdWV1ZXMKb3B0aW9u cyAJU1lTVlNFTQkJCSMgU1lTVi1zdHlsZSBzZW1hcGhvcmVzCm9wdGlvbnMgCV9LUE9TSVhfUFJJ T1JJVFlfU0NIRURVTElORyAjIFBPU0lYIFAxMDAzXzFCIHJlYWwtdGltZSBleHRlbnNpb25zCm9w dGlvbnMgCVBSSU5URl9CVUZSX1NJWkU9MTI4CSMgUHJldmVudCBwcmludGYgb3V0cHV0IGJlaW5n IGludGVyc3BlcnNlZC4Kb3B0aW9ucyAJS0JEX0lOU1RBTExfQ0RFVgkjIGluc3RhbGwgYSBDREVW IGVudHJ5IGluIC9kZXYKb3B0aW9ucyAJSFdQTUNfSE9PS1MJCSMgTmVjZXNzYXJ5IGtlcm5lbCBo b29rcyBmb3IgaHdwbWMoNCkKb3B0aW9ucyAJQVVESVQJCQkjIFNlY3VyaXR5IGV2ZW50IGF1ZGl0 aW5nCm9wdGlvbnMgCUNBUEFCSUxJVFlfTU9ERQkJIyBDYXBzaWN1bSBjYXBhYmlsaXR5IG1vZGUK b3B0aW9ucyAJQ0FQQUJJTElUSUVTCQkjIENhcHNpY3VtIGNhcGFiaWxpdGllcwpvcHRpb25zIAlN QUMJCQkjIFRydXN0ZWRCU0QgTUFDIEZyYW1ld29yawpvcHRpb25zIAlLRFRSQUNFX0hPT0tTCQkj IEtlcm5lbCBEVHJhY2UgaG9va3MKb3B0aW9ucyAJRERCX0NURgkJCSMgS2VybmVsIEVMRiBsaW5r ZXIgbG9hZHMgQ1RGIGRhdGEKb3B0aW9ucyAJSU5DTFVERV9DT05GSUdfRklMRQkjIEluY2x1ZGUg dGhpcyBmaWxlIGluIGtlcm5lbAoKIyBEZWJ1Z2dpbmcgc3VwcG9ydC4gIEFsd2F5cyBuZWVkIHRo aXM6Cm9wdGlvbnMgCUtEQgkJCSMgRW5hYmxlIGtlcm5lbCBkZWJ1Z2dlciBzdXBwb3J0LgpvcHRp b25zIAlLREJfVFJBQ0UJCSMgUHJpbnQgYSBzdGFjayB0cmFjZSBmb3IgYSBwYW5pYy4KIyBGb3Ig ZnVsbCBkZWJ1Z2dlciBzdXBwb3J0IHVzZSAodHVybiBvZmYgaW4gc3RhYmxlIGJyYW5jaCk6Cm9w dGlvbnMgCUREQgkJCSMgU3VwcG9ydCBEREIuCm9wdGlvbnMgCUdEQgkJCSMgU3VwcG9ydCByZW1v dGUgR0RCLgpvcHRpb25zIAlERUFETEtSRVMJCSMgRW5hYmxlIHRoZSBkZWFkbG9jayByZXNvbHZl cgpvcHRpb25zIAlJTlZBUklBTlRTCQkjIEVuYWJsZSBjYWxscyBvZiBleHRyYSBzYW5pdHkgY2hl Y2tpbmcKb3B0aW9ucyAJSU5WQVJJQU5UX1NVUFBPUlQJIyBFeHRyYSBzYW5pdHkgY2hlY2tzIG9m IGludGVybmFsIHN0cnVjdHVyZXMsIHJlcXVpcmVkIGJ5IElOVkFSSUFOVFMKb3B0aW9ucyAJV0lU TkVTUwkJCSMgRW5hYmxlIGNoZWNrcyB0byBkZXRlY3QgZGVhZGxvY2tzIGFuZCBjeWNsZXMKb3B0 aW9ucyAJV0lUTkVTU19TS0lQU1BJTgkjIERvbid0IHJ1biB3aXRuZXNzIG9uIHNwaW5sb2NrcyBm b3Igc3BlZWQKb3B0aW9ucyAJTUFMTE9DX0RFQlVHX01BWFpPTkVTPTgJIyBTZXBhcmF0ZSBtYWxs b2MoOSkgem9uZXMKCiMgVG8gbWFrZSBhbiBTTVAga2VybmVsLCB0aGUgbmV4dCB0d28gbGluZXMg YXJlIG5lZWRlZApvcHRpb25zIAlTTVAJCQkjIFN5bW1ldHJpYyBNdWx0aVByb2Nlc3NvciBLZXJu ZWwKZGV2aWNlCQlhcGljCQkJIyBJL08gQVBJQwoKIyBDUFUgZnJlcXVlbmN5IGNvbnRyb2wKZGV2 aWNlCQljcHVmcmVxCgojIEJ1cyBzdXBwb3J0LgpkZXZpY2UJCWFjcGkKZGV2aWNlCQlwY2kKCiMg RmxvcHB5IGRyaXZlcwpkZXZpY2UJCWZkYwoKIyBBVEEgY29udHJvbGxlcnMKZGV2aWNlCQlhaGNp CQkJIyBBSENJLWNvbXBhdGlibGUgU0FUQSBjb250cm9sbGVycwpkZXZpY2UJCWF0YQkJCSMgTGVn YWN5IEFUQS9TQVRBIGNvbnRyb2xsZXJzCm9wdGlvbnMgCUFUQV9TVEFUSUNfSUQJCSMgU3RhdGlj IGRldmljZSBudW1iZXJpbmcKZGV2aWNlCQltdnMJCQkjIE1hcnZlbGwgODhTWDUwWFgvODhTWDYw WFgvODhTWDcwWFgvU29DIFNBVEEKZGV2aWNlCQlzaWlzCQkJIyBTaWxpY29uSW1hZ2UgU2lJMzEy NC9TaUkzMTMyL1NpSTM1MzEgU0FUQQoKIyBTQ1NJIENvbnRyb2xsZXJzCmRldmljZQkJYWhjCQkJ IyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4eHggZGV2aWNlcwpvcHRpb25zIAlBSENfUkVHX1BS RVRUWV9QUklOVAkjIFByaW50IHJlZ2lzdGVyIGJpdGZpZWxkcyBpbiBkZWJ1ZwoJCQkJCSMgb3V0 cHV0LiAgQWRkcyB+MTI4ayB0byBkcml2ZXIuCmRldmljZQkJYWhkCQkJIyBBSEEzOTMyMC8yOTMy MCBhbmQgb25ib2FyZCBBSUM3OXh4IGRldmljZXMKb3B0aW9ucyAJQUhEX1JFR19QUkVUVFlfUFJJ TlQJIyBQcmludCByZWdpc3RlciBiaXRmaWVsZHMgaW4gZGVidWcKCQkJCQkjIG91dHB1dC4gIEFk ZHMgfjIxNWsgdG8gZHJpdmVyLgpkZXZpY2UJCWVzcAkJCSMgQU1EIEFtNTNDOTc0IChUZWtyYW0g REMtMzkwKFQpKQpkZXZpY2UJCWhwdGlvcAkJCSMgSGlnaHBvaW50IFJvY2tldFJhaWQgM3h4eCBz ZXJpZXMKZGV2aWNlCQlpc3AJCQkjIFFsb2dpYyBmYW1pbHkKI2RldmljZQkJaXNwZncJCQkjIEZp cm13YXJlIGZvciBRTG9naWMgSEJBcy0gbm9ybWFsbHkgYSBtb2R1bGUKZGV2aWNlCQltcHQJCQkj IExTSS1Mb2dpYyBNUFQtRnVzaW9uCmRldmljZQkJbXBzCQkJIyBMU0ktTG9naWMgTVBULUZ1c2lv biAyCmRldmljZQkJbXByCQkJIyBMU0ktTG9naWMgTVBULUZ1c2lvbiAzCiNkZXZpY2UJCW5jcgkJ CSMgTkNSL1N5bWJpb3MgTG9naWMKZGV2aWNlCQlzeW0JCQkjIE5DUi9TeW1iaW9zIExvZ2ljIChu ZXdlciBjaGlwc2V0cyArIHRob3NlIG9mIGBuY3InKQpkZXZpY2UJCXRybQkJCSMgVGVrcmFtIERD Mzk1VS9VVy9GIERDMzE1VSBhZGFwdGVycwoKZGV2aWNlCQlhZHYJCQkjIEFkdmFuc3lzIFNDU0kg YWRhcHRlcnMKZGV2aWNlCQlhZHcJCQkjIEFkdmFuc3lzIHdpZGUgU0NTSSBhZGFwdGVycwpkZXZp Y2UJCWFoYQkJCSMgQWRhcHRlYyAxNTR4IFNDU0kgYWRhcHRlcnMKZGV2aWNlCQlhaWMJCQkjIEFk YXB0ZWMgMTVbMDEyXXggU0NTSSBhZGFwdGVycywgQUlDLTZbMjNdNjAuCmRldmljZQkJYnQJCQkj IEJ1c2xvZ2ljL015bGV4IE11bHRpTWFzdGVyIFNDU0kgYWRhcHRlcnMKCmRldmljZQkJbmN2CQkJ IyBOQ1IgNTNDNTAwCmRldmljZQkJbnNwCQkJIyBXb3JrYml0IE5pbmphIFNDU0ktMwpkZXZpY2UJ CXN0ZwkJCSMgVE1DIDE4QzMwLzE4QzUwCmRldmljZQkJaXNjaQkJCSMgSW50ZWwgQzYwMCBTQVMg Y29udHJvbGxlcgoKIyBBVEEvU0NTSSBwZXJpcGhlcmFscwpkZXZpY2UJCXNjYnVzCQkJIyBTQ1NJ IGJ1cyAocmVxdWlyZWQgZm9yIEFUQS9TQ1NJKQpkZXZpY2UJCWNoCQkJIyBTQ1NJIG1lZGlhIGNo YW5nZXJzCmRldmljZQkJZGEJCQkjIERpcmVjdCBBY2Nlc3MgKGRpc2tzKQpkZXZpY2UJCXNhCQkJ IyBTZXF1ZW50aWFsIEFjY2VzcyAodGFwZSBldGMpCmRldmljZQkJY2QJCQkjIENECmRldmljZQkJ cGFzcwkJCSMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3QgQVRBL1NDU0kgYWNjZXNzKQpkZXZp Y2UJCXNlcwkJCSMgRW5jbG9zdXJlIFNlcnZpY2VzIChTRVMgYW5kIFNBRi1URSkKI2RldmljZQkJ Y3RsCQkJIyBDQU0gVGFyZ2V0IExheWVyCgojIFJBSUQgY29udHJvbGxlcnMgaW50ZXJmYWNlZCB0 byB0aGUgU0NTSSBzdWJzeXN0ZW0KZGV2aWNlCQlhbXIJCQkjIEFNSSBNZWdhUkFJRApkZXZpY2UJ CWFyY21zcgkJCSMgQXJlY2EgU0FUQSBJSSBSQUlECmRldmljZQkJYXNyCQkJIyBEUFQgU21hcnRS QUlEIFYsIFZJIGFuZCBBZGFwdGVjIFNDU0kgUkFJRApkZXZpY2UJCWNpc3MJCQkjIENvbXBhcSBT bWFydCBSQUlEIDUqCmRldmljZQkJZHB0CQkJIyBEUFQgU21hcnRjYWNoZSBJSUksIElWIC0gU2Vl IE5PVEVTIGZvciBvcHRpb25zCmRldmljZQkJaHB0bXYJCQkjIEhpZ2hwb2ludCBSb2NrZXRSQUlE IDE4MngKZGV2aWNlCQlocHRucgkJCSMgSGlnaHBvaW50IERDNzI4MCwgUjc1MApkZXZpY2UJCWhw dHJyCQkJIyBIaWdocG9pbnQgUm9ja2V0UkFJRCAxN3h4LCAyMnh4LCAyM3h4LCAyNXh4CmRldmlj ZQkJaHB0Mjd4eAkJCSMgSGlnaHBvaW50IFJvY2tldFJBSUQgMjd4eApkZXZpY2UJCWlpcgkJCSMg SW50ZWwgSW50ZWdyYXRlZCBSQUlECmRldmljZQkJaXBzCQkJIyBJQk0gKEFkYXB0ZWMpIFNlcnZl UkFJRApkZXZpY2UJCW1seQkJCSMgTXlsZXggQWNjZWxlUkFJRC9lWHRyZW1lUkFJRApkZXZpY2UJ CXR3YQkJCSMgM3dhcmUgOTAwMCBzZXJpZXMgUEFUQS9TQVRBIFJBSUQKZGV2aWNlCQl0d3MJCQkj IExTSSAzd2FyZSA5NzUwIFNBVEErU0FTIDZHYi9zIFJBSUQgY29udHJvbGxlcgoKIyBSQUlEIGNv bnRyb2xsZXJzCmRldmljZQkJYWFjCQkJIyBBZGFwdGVjIEZTQSBSQUlECmRldmljZQkJYWFjcAkJ CSMgU0NTSSBwYXNzdGhyb3VnaCBmb3IgYWFjIChyZXF1aXJlcyBDQU0pCmRldmljZQkJYWFjcmFp ZAkJCSMgQWRhcHRlYyBieSBQTUMgUkFJRApkZXZpY2UJCWlkYQkJCSMgQ29tcGFxIFNtYXJ0IFJB SUQKZGV2aWNlCQltZmkJCQkjIExTSSBNZWdhUkFJRCBTQVMKZGV2aWNlCQltbHgJCQkjIE15bGV4 IERBQzk2MCBmYW1pbHkKZGV2aWNlCQltcnNhcwkJCSMgTFNJL0F2YWdvIE1lZ2FSQUlEIFNBUy9T QVRBLCA2R2IvcyBhbmQgMTJHYi9zCmRldmljZQkJcHN0CQkJIyBQcm9taXNlIFN1cGVydHJhayBT WDYwMDAKZGV2aWNlCQl0d2UJCQkjIDN3YXJlIEFUQSBSQUlECgojIGF0a2JkYzAgY29udHJvbHMg Ym90aCB0aGUga2V5Ym9hcmQgYW5kIHRoZSBQUy8yIG1vdXNlCmRldmljZQkJYXRrYmRjCQkJIyBB VCBrZXlib2FyZCBjb250cm9sbGVyCmRldmljZQkJYXRrYmQJCQkjIEFUIGtleWJvYXJkCmRldmlj ZQkJcHNtCQkJIyBQUy8yIG1vdXNlCgpkZXZpY2UJCWtiZG11eAkJCSMga2V5Ym9hcmQgbXVsdGlw bGV4ZXIKCmRldmljZQkJdmdhCQkJIyBWR0EgdmlkZW8gY2FyZCBkcml2ZXIKb3B0aW9ucyAJVkVT QQkJCSMgQWRkIHN1cHBvcnQgZm9yIFZFU0EgQklPUyBFeHRlbnNpb25zIChWQkUpCgpkZXZpY2UJ CXNwbGFzaAkJCSMgU3BsYXNoIHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQKCiMgc3lz Y29ucyBpcyB0aGUgZGVmYXVsdCBjb25zb2xlIGRyaXZlciwgcmVzZW1ibGluZyBhbiBTQ08gY29u c29sZQpkZXZpY2UJCXNjCm9wdGlvbnMgCVNDX1BJWEVMX01PREUJCSMgYWRkIHN1cHBvcnQgZm9y IHRoZSByYXN0ZXIgdGV4dCBtb2RlCgojIHZ0IGlzIHRoZSBuZXcgdmlkZW8gY29uc29sZSBkcml2 ZXIKZGV2aWNlCQl2dApkZXZpY2UJCXZ0X3ZnYQoKZGV2aWNlCQlhZ3AJCQkjIHN1cHBvcnQgc2V2 ZXJhbCBBR1AgY2hpcHNldHMKCiMgUG93ZXIgbWFuYWdlbWVudCBzdXBwb3J0IChzZWUgTk9URVMg Zm9yIG1vcmUgb3B0aW9ucykKI2RldmljZQkJYXBtCiMgQWRkIHN1c3BlbmQvcmVzdW1lIHN1cHBv cnQgZm9yIHRoZSBpODI1NC4KZGV2aWNlCQlwbXRpbWVyCgojIFBDQ0FSRCAoUENNQ0lBKSBzdXBw b3J0CiMgUENNQ0lBIGFuZCBjYXJkYnVzIGJyaWRnZSBzdXBwb3J0CmRldmljZQkJY2JiCQkJIyBj YXJkYnVzICh5ZW50YSkgYnJpZGdlCmRldmljZQkJcGNjYXJkCQkJIyBQQyBDYXJkICgxNi1iaXQp IGJ1cwpkZXZpY2UJCWNhcmRidXMJCQkjIENhcmRCdXMgKDMyLWJpdCkgYnVzCgojIFNlcmlhbCAo Q09NKSBwb3J0cwpkZXZpY2UJCXVhcnQJCQkjIEdlbmVyaWMgVUFSVCBkcml2ZXIKCiMgUGFyYWxs ZWwgcG9ydApkZXZpY2UJCXBwYwpkZXZpY2UJCXBwYnVzCQkJIyBQYXJhbGxlbCBwb3J0IGJ1cyAo cmVxdWlyZWQpCmRldmljZQkJbHB0CQkJIyBQcmludGVyCmRldmljZQkJcHBpCQkJIyBQYXJhbGxl bCBwb3J0IGludGVyZmFjZSBkZXZpY2UKI2RldmljZQkJdnBvCQkJIyBSZXF1aXJlcyBzY2J1cyBh bmQgZGEKCmRldmljZQkJcHVjCQkJIyBNdWx0aSBJL08gY2FyZHMgYW5kIG11bHRpLWNoYW5uZWwg VUFSVHMKCiMgUENJIEV0aGVybmV0IE5JQ3MuCmRldmljZQkJYnhlCQkJIyBCcm9hZGNvbSBOZXRY dHJlbWUgSUkgQkNNNTc3MVgvQkNNNTc4WFggMTBHYkUKZGV2aWNlCQlkZQkJCSMgREVDL0ludGVs IERDMjF4NHggKGBgVHVsaXAnJykKZGV2aWNlCQllbQkJCSMgSW50ZWwgUFJPLzEwMDAgR2lnYWJp dCBFdGhlcm5ldCBGYW1pbHkKZGV2aWNlCQlpZ2IJCQkjIEludGVsIFBSTy8xMDAwIFBDSUUgU2Vy dmVyIEdpZ2FiaXQgRmFtaWx5CmRldmljZQkJaXhnYgkJCSMgSW50ZWwgUFJPLzEwR2JFIEV0aGVy bmV0IENhcmQKZGV2aWNlCQlsZQkJCSMgQU1EIEFtNzkwMCBMQU5DRSBhbmQgQW03OUM5eHggUENu ZXQKZGV2aWNlCQl0aQkJCSMgQWx0ZW9uIE5ldHdvcmtzIFRpZ29uIEkvSUkgZ2lnYWJpdCBFdGhl cm5ldApkZXZpY2UJCXR4cAkJCSMgM0NvbSAzY1I5OTAgKGBgVHlwaG9vbicnKQpkZXZpY2UJCXZ4 CQkJIyAzQ29tIDNjNTkwLCAzYzU5NSAoYGBWb3J0ZXgnJykKCiMgUENJIEV0aGVybmV0IE5JQ3Mg dGhhdCB1c2UgdGhlIGNvbW1vbiBNSUkgYnVzIGNvbnRyb2xsZXIgY29kZS4KIyBOT1RFOiBCZSBz dXJlIHRvIGtlZXAgdGhlICdkZXZpY2UgbWlpYnVzJyBsaW5lIGluIG9yZGVyIHRvIHVzZSB0aGVz ZSBOSUNzIQpkZXZpY2UJCW1paWJ1cwkJCSMgTUlJIGJ1cyBzdXBwb3J0CmRldmljZQkJYWUJCQkj IEF0dGFuc2ljL0F0aGVyb3MgTDIgRmFzdEV0aGVybmV0CmRldmljZQkJYWdlCQkJIyBBdHRhbnNp Yy9BdGhlcm9zIEwxIEdpZ2FiaXQgRXRoZXJuZXQKZGV2aWNlCQlhbGMJCQkjIEF0aGVyb3MgQVI4 MTMxL0FSODEzMiBFdGhlcm5ldApkZXZpY2UJCWFsZQkJCSMgQXRoZXJvcyBBUjgxMjEvQVI4MTEz L0FSODExNCBFdGhlcm5ldApkZXZpY2UJCWJjZQkJCSMgQnJvYWRjb20gQkNNNTcwNi9CQ001NzA4 IEdpZ2FiaXQgRXRoZXJuZXQKZGV2aWNlCQliZmUJCQkjIEJyb2FkY29tIEJDTTQ0MHggMTAvMTAw IEV0aGVybmV0CmRldmljZQkJYmdlCQkJIyBCcm9hZGNvbSBCQ001NzB4eCBHaWdhYml0IEV0aGVy bmV0CmRldmljZQkJY2FzCQkJIyBTdW4gQ2Fzc2luaS9DYXNzaW5pKyBhbmQgTlMgRFA4MzA2NSBT YXR1cm4KZGV2aWNlCQlkYwkJCSMgREVDL0ludGVsIDIxMTQzIGFuZCB2YXJpb3VzIHdvcmthbGlr ZXMKZGV2aWNlCQlldAkJCSMgQWdlcmUgRVQxMzEwIDEwLzEwMC9HaWdhYml0IEV0aGVybmV0CmRl dmljZQkJZnhwCQkJIyBJbnRlbCBFdGhlckV4cHJlc3MgUFJPLzEwMEIgKDgyNTU3LCA4MjU1OCkK ZGV2aWNlCQlnZW0JCQkjIFN1biBHRU0vU3VuIEVSSS9BcHBsZSBHTUFDCmRldmljZQkJaG1lCQkJ IyBTdW4gSE1FIChIYXBweSBNZWFsIEV0aGVybmV0KQpkZXZpY2UJCWptZQkJCSMgSk1pY3JvbiBK TUMyNTAgR2lnYWJpdC9KTUMyNjAgRmFzdCBFdGhlcm5ldApkZXZpY2UJCWxnZQkJCSMgTGV2ZWwg MSBMWFQxMDAxIGdpZ2FiaXQgRXRoZXJuZXQKZGV2aWNlCQltc2sJCQkjIE1hcnZlbGwvU3lzS29u bmVjdCBZdWtvbiBJSSBHaWdhYml0IEV0aGVybmV0CmRldmljZQkJbmZlCQkJIyBuVmlkaWEgbkZv cmNlIE1DUCBvbi1ib2FyZCBFdGhlcm5ldApkZXZpY2UJCW5nZQkJCSMgTmF0U2VtaSBEUDgzODIw IGdpZ2FiaXQgRXRoZXJuZXQKZGV2aWNlCQlwY24JCQkjIEFNRCBBbTc5Qzk3eCBQQ0kgMTAvMTAw IChwcmVjZWRlbmNlIG92ZXIgJ2xlJykKZGV2aWNlCQlyZQkJCSMgUmVhbFRlayA4MTM5QysvODE2 OS84MTY5Uy84MTEwUwpkZXZpY2UJCXJsCQkJIyBSZWFsVGVrIDgxMjkvODEzOQpkZXZpY2UJCXNm CQkJIyBBZGFwdGVjIEFJQy02OTE1IChgYFN0YXJmaXJlJycpCmRldmljZQkJc2dlCQkJIyBTaWxp Y29uIEludGVncmF0ZWQgU3lzdGVtcyBTaVMxOTAvMTkxCmRldmljZQkJc2lzCQkJIyBTaWxpY29u IEludGVncmF0ZWQgU3lzdGVtcyBTaVMgOTAwL1NpUyA3MDE2CmRldmljZQkJc2sJCQkjIFN5c0tv bm5lY3QgU0stOTg0eCAmIFNLLTk4MnggZ2lnYWJpdCBFdGhlcm5ldApkZXZpY2UJCXN0ZQkJCSMg U3VuZGFuY2UgU1QyMDEgKEQtTGluayBERkUtNTUwVFgpCmRldmljZQkJc3RnZQkJCSMgU3VuZGFu Y2UvVGFtYXJhY2sgVEM5MDIxIGdpZ2FiaXQgRXRoZXJuZXQKZGV2aWNlCQl0bAkJCSMgVGV4YXMg SW5zdHJ1bWVudHMgVGh1bmRlckxBTgpkZXZpY2UJCXR4CQkJIyBTTUMgRXRoZXJQb3dlciBJSSAo ODNjMTcwIGBgRVBJQycnKQpkZXZpY2UJCXZnZQkJCSMgVklBIFZUNjEyeCBnaWdhYml0IEV0aGVy bmV0CmRldmljZQkJdnIJCQkjIFZJQSBSaGluZSwgUmhpbmUgSUkKZGV2aWNlCQl2dGUJCQkjIERN JlAgVm9ydGV4ODYgUkRDIFI2MDQwIEZhc3QgRXRoZXJuZXQKZGV2aWNlCQl3YgkJCSMgV2luYm9u ZCBXODlDODQwRgpkZXZpY2UJCXhsCQkJIyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycnLCBgYEN5 Y2xvbmUnJykKCiMgSVNBIEV0aGVybmV0IE5JQ3MuICBwY2NhcmQgTklDcyBpbmNsdWRlZC4KZGV2 aWNlCQljcwkJCSMgQ3J5c3RhbCBTZW1pY29uZHVjdG9yIENTODl4MCBOSUMKIyAnZGV2aWNlIGVk JyByZXF1aXJlcyAnZGV2aWNlIG1paWJ1cycKZGV2aWNlCQllZAkJCSMgTkVbMTJdMDAwLCBTTUMg VWx0cmEsIDNjNTAzLCBEUzgzOTAgY2FyZHMKZGV2aWNlCQlleAkJCSMgSW50ZWwgRXRoZXJFeHBy ZXNzIFByby8xMCBhbmQgUHJvLzEwKwpkZXZpY2UJCWVwCQkJIyBFdGhlcmxpbmsgSUlJIGJhc2Vk IGNhcmRzCmRldmljZQkJZmUJCQkjIEZ1aml0c3UgTUI4Njk2eCBiYXNlZCBjYXJkcwpkZXZpY2UJ CWllCQkJIyBFdGhlckV4cHJlc3MgOC8xNiwgM0M1MDcsIFN0YXJMQU4gMTAgZXRjLgpkZXZpY2UJ CXNuCQkJIyBTTUMncyA5MDAwIHNlcmllcyBvZiBFdGhlcm5ldCBjaGlwcwpkZXZpY2UJCXhlCQkJ IyBYaXJjb20gcGNjYXJkIEV0aGVybmV0CgojIFdpcmVsZXNzIE5JQyBjYXJkcwpkZXZpY2UJCXds YW4JCQkjIDgwMi4xMSBzdXBwb3J0Cm9wdGlvbnMgCUlFRUU4MDIxMV9ERUJVRwkJIyBlbmFibGUg ZGVidWcgbXNncwpvcHRpb25zIAlJRUVFODAyMTFfQU1QRFVfQUdFCSMgYWdlIGZyYW1lcyBpbiBB TVBEVSByZW9yZGVyIHEncwpvcHRpb25zIAlJRUVFODAyMTFfU1VQUE9SVF9NRVNICSMgZW5hYmxl IDgwMi4xMXMgZHJhZnQgc3VwcG9ydApkZXZpY2UJCXdsYW5fd2VwCQkjIDgwMi4xMSBXRVAgc3Vw cG9ydApkZXZpY2UJCXdsYW5fY2NtcAkJIyA4MDIuMTEgQ0NNUCBzdXBwb3J0CmRldmljZQkJd2xh bl90a2lwCQkjIDgwMi4xMSBUS0lQIHN1cHBvcnQKZGV2aWNlCQl3bGFuX2FtcnIJCSMgQU1SUiB0 cmFuc21pdCByYXRlIGNvbnRyb2wgYWxnb3JpdGhtCmRldmljZQkJYW4JCQkjIEFpcm9uZXQgNDUw MC80ODAwIDgwMi4xMSB3aXJlbGVzcyBOSUNzLgpkZXZpY2UJCWF0aAkJCSMgQXRoZXJvcyBOSUNz CmRldmljZQkJYXRoX3BjaQkJCSMgQXRoZXJvcyBwY2kvY2FyZGJ1cyBnbHVlCmRldmljZQkJYXRo X2hhbAkJCSMgcGNpL2NhcmRidXMgY2hpcCBzdXBwb3J0Cm9wdGlvbnMgCUFIX1NVUFBPUlRfQVI1 NDE2CSMgZW5hYmxlIEFSNTQxNiB0eC9yeCBkZXNjcmlwdG9ycwpvcHRpb25zIAlBSF9BUjU0MTZf SU5URVJSVVBUX01JVElHQVRJT04gIyBBUjU0MTYgaW50ZXJydXB0IG1pdGlnYXRpb24Kb3B0aW9u cyAJQVRIX0VOQUJMRV8xMU4JCSMgRW5hYmxlIDgwMi4xMW4gc3VwcG9ydCBmb3IgQVI1NDE2IGFu ZCBsYXRlcgpkZXZpY2UJCWF0aF9yYXRlX3NhbXBsZQkJIyBTYW1wbGVSYXRlIHR4IHJhdGUgY29u dHJvbCBmb3IgYXRoCiNkZXZpY2UJCWJ3aQkJCSMgQnJvYWRjb20gQkNNNDMweC9CQ000MzF4IHdp cmVsZXNzIE5JQ3MuCiNkZXZpY2UJCWJ3bgkJCSMgQnJvYWRjb20gQkNNNDN4eCB3aXJlbGVzcyBO SUNzLgpkZXZpY2UJCWlwdwkJCSMgSW50ZWwgMjEwMCB3aXJlbGVzcyBOSUNzLgpkZXZpY2UJCWl3 aQkJCSMgSW50ZWwgMjIwMEJHLzIyMjVCRy8yOTE1QUJHIHdpcmVsZXNzIE5JQ3MuCmRldmljZQkJ aXduCQkJIyBJbnRlbCA0OTY1LzEwMDAvNTAwMC82MDAwIHdpcmVsZXNzIE5JQ3MuCmRldmljZQkJ bWFsbwkJCSMgTWFydmVsbCBMaWJlcnRhcyB3aXJlbGVzcyBOSUNzLgpkZXZpY2UJCW13bAkJCSMg TWFydmVsbCA4OFc4MzYzIDgwMi4xMW4gd2lyZWxlc3MgTklDcy4KZGV2aWNlCQlyYWwJCQkjIFJh bGluayBUZWNobm9sb2d5IFJUMjUwMCB3aXJlbGVzcyBOSUNzLgpkZXZpY2UJCXdpCQkJIyBXYXZl TEFOL0ludGVyc2lsL1N5bWJvbCA4MDIuMTEgd2lyZWxlc3MgTklDcy4KI2RldmljZQkJd2wJCQkj IE9sZGVyIG5vbiA4MDIuMTEgV2F2ZWxhbiB3aXJlbGVzcyBOSUMuCmRldmljZQkJd3BpCQkJIyBJ bnRlbCAzOTQ1QUJHIHdpcmVsZXNzIE5JQ3MuCgojIFBzZXVkbyBkZXZpY2VzLgpkZXZpY2UJCWxv b3AJCQkjIE5ldHdvcmsgbG9vcGJhY2sKZGV2aWNlCQlyYW5kb20JCQkjIEVudHJvcHkgZGV2aWNl CmRldmljZQkJcGFkbG9ja19ybmcJCSMgVklBIFBhZGxvY2sgUk5HCmRldmljZQkJcmRyYW5kX3Ju ZwkJIyBJbnRlbCBCdWxsIE1vdW50YWluIFJORwpkZXZpY2UJCWV0aGVyCQkJIyBFdGhlcm5ldCBz dXBwb3J0CmRldmljZQkJdmxhbgkJCSMgODAyLjFRIFZMQU4gc3VwcG9ydApkZXZpY2UJCXR1bgkJ CSMgUGFja2V0IHR1bm5lbC4KZGV2aWNlCQltZAkJCSMgTWVtb3J5ICJkaXNrcyIKZGV2aWNlCQln aWYJCQkjIElQdjYgYW5kIElQdjQgdHVubmVsaW5nCmRldmljZQkJZmFpdGgJCQkjIElQdjYtdG8t SVB2NCByZWxheWluZyAodHJhbnNsYXRpb24pCmRldmljZQkJZmlybXdhcmUJCSMgZmlybXdhcmUg YXNzaXN0IG1vZHVsZQoKIyBUaGUgYGJwZicgZGV2aWNlIGVuYWJsZXMgdGhlIEJlcmtlbGV5IFBh Y2tldCBGaWx0ZXIuCiMgQmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0cmF0aXZlIGNvbnNlcXVlbmNl cyBvZiBlbmFibGluZyB0aGlzIQojIE5vdGUgdGhhdCAnYnBmJyBpcyByZXF1aXJlZCBmb3IgREhD UC4KZGV2aWNlCQlicGYJCQkjIEJlcmtlbGV5IHBhY2tldCBmaWx0ZXIKCiMgVVNCIHN1cHBvcnQK b3B0aW9ucyAJVVNCX0RFQlVHCQkjIGVuYWJsZSBkZWJ1ZyBtc2dzCmRldmljZQkJdWhjaQkJCSMg VUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UKZGV2aWNlCQlvaGNpCQkJIyBPSENJIFBDSS0+VVNCIGlu dGVyZmFjZQpkZXZpY2UJCWVoY2kJCQkjIEVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlIChVU0IgMi4w KQpkZXZpY2UJCXhoY2kJCQkjIFhIQ0kgUENJLT5VU0IgaW50ZXJmYWNlIChVU0IgMy4wKQpkZXZp Y2UJCXVzYgkJCSMgVVNCIEJ1cyAocmVxdWlyZWQpCmRldmljZQkJdWtiZAkJCSMgS2V5Ym9hcmQK ZGV2aWNlCQl1bWFzcwkJCSMgRGlza3MvTWFzcyBzdG9yYWdlIC0gUmVxdWlyZXMgc2NidXMgYW5k IGRhCgojIFNvdW5kIHN1cHBvcnQKZGV2aWNlCQlzb3VuZAkJCSMgR2VuZXJpYyBzb3VuZCBkcml2 ZXIgKHJlcXVpcmVkKQpkZXZpY2UJCXNuZF9jbWkJCQkjIENNZWRpYSBDTUk4MzM4L0NNSTg3MzgK ZGV2aWNlCQlzbmRfY3NhCQkJIyBDcnlzdGFsIFNlbWljb25kdWN0b3IgQ1M0NjF4LzQyOHgKZGV2 aWNlCQlzbmRfZW11MTBreAkJIyBDcmVhdGl2ZSBTb3VuZEJsYXN0ZXIgTGl2ZSEgYW5kIEF1ZGln eQpkZXZpY2UJCXNuZF9lczEzN3gJCSMgRW5zb25pcSBBdWRpb1BDSSBFUzEzN3gKZGV2aWNlCQlz bmRfaGRhCQkJIyBJbnRlbCBIaWdoIERlZmluaXRpb24gQXVkaW8KZGV2aWNlCQlzbmRfaWNoCQkJ IyBJbnRlbCwgTlZpZGlhIGFuZCBvdGhlciBJQ0ggQUMnOTcgQXVkaW8KZGV2aWNlCQlzbmRfdmlh ODIzMwkJIyBWSUEgVlQ4MjMzeCBBdWRpbwoKIyBNTUMvU0QKZGV2aWNlCQltbWMJCQkjIE1NQy9T RCBidXMKZGV2aWNlCQltbWNzZAkJCSMgTU1DL1NEIG1lbW9yeSBjYXJkCmRldmljZQkJc2RoY2kJ CQkjIEdlbmVyaWMgUENJIFNEIEhvc3QgQ29udHJvbGxlcgoKIyBWaXJ0SU8gc3VwcG9ydApkZXZp Y2UJCXZpcnRpbwkJCSMgR2VuZXJpYyBWaXJ0SU8gYnVzIChyZXF1aXJlZCkKZGV2aWNlCQl2aXJ0 aW9fcGNpCQkjIFZpcnRJTyBQQ0kgZGV2aWNlCmRldmljZQkJdnRuZXQJCQkjIFZpcnRJTyBFdGhl cm5ldCBkZXZpY2UKZGV2aWNlCQl2aXJ0aW9fYmxrCQkjIFZpcnRJTyBCbG9jayBkZXZpY2UKZGV2 aWNlCQl2aXJ0aW9fc2NzaQkJIyBWaXJ0SU8gU0NTSSBkZXZpY2UKZGV2aWNlCQl2aXJ0aW9fYmFs bG9vbgkJIyBWaXJ0SU8gTWVtb3J5IEJhbGxvb24gZGV2aWNlCgojIEh5cGVyViBkcml2ZXJzCmRl dmljZQkJaHlwZXJ2CQkJIyBIeXBlclYgZHJpdmVycyAKCiMgWGVuIEhWTSBHdWVzdCBPcHRpbWl6 YXRpb25zCiMgTk9URTogWEVOSFZNIGRlcGVuZHMgb24geGVucGNpLiAgVGhleSBtdXN0IGJlIGFk ZGVkIG9yIHJlbW92ZWQgdG9nZXRoZXIuCm9wdGlvbnMgCVhFTkhWTQkJCSMgWGVuIEhWTSBrZXJu ZWwgaW5mcmFzdHJ1Y3R1cmUKZGV2aWNlCQl4ZW5wY2kJCQkjIFhlbiBIVk0gSHlwZXJ2aXNvciBz ZXJ2aWNlcyBkcml2ZXIKCiMgVk13YXJlIHN1cHBvcnQKZGV2aWNlCQl2bXgJCQkjIFZNd2FyZSBW TVhORVQzIEV0aGVybmV0CgojU09FS1JJUyBhZGRpdGlvbnMKb3B0aW9ucyAJQ1BVX1NPRUtSSVMK b3B0aW9ucyAJQ1BVX0VMQU4KI29wdGlvbnMgCUNQVV9FTEFOX1BQUwojb3B0aW9ucyAJQ1BVX0VM QU5fWFRBTD0zMjc2ODAwMApvcHRpb25zIAlDUFVfR0VPREUKb3B0aW9ucyAJVE1QRlMKCg== --089e01538746ce17f40504172b37-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 03:22:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6A70B7 for ; Sun, 28 Sep 2014 03:22:17 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B9D9C8D1 for ; Sun, 28 Sep 2014 03:22:17 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id v10so13337845pde.22 for ; Sat, 27 Sep 2014 20:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8qz7E/oQFg8ykPyL7SdPshezBu6odmp+ehzJpmKSGGQ=; b=I8s8KARgrGKukWL29FPpZBeHLybXH9WDO1kVg06wxaKAEsSqJn4/q4apq/HP0QB78b GZsjidQu7/dNtgbl4oNgctqB9GtsrlXDNrgunWqwdjQDvSHblWuM2flpO7JGOqNbw8ny 7R/v+0eb/IvZWZ2El4d0uPywMFLD6gn8yBQSQV9eASDD7DIokyrI+KR9JcemIiz5CtBy ByNWLGlXD1e6DPPl9d0lPxsCPLvQY+T2Pvlh36Q1vxqVM/jLt1KzwNFu3NyJnGA5dNiQ qcf7hkOQahBP0DPJCEDOwXIJwzR1PDWwSu5oq7iwrldaXrlHwwcnCuAOZnFk18/B93Q2 ClsQ== X-Received: by 10.66.137.2 with SMTP id qe2mr6454102pab.133.1411874537245; Sat, 27 Sep 2014 20:22:17 -0700 (PDT) Received: from [192.168.1.7] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id ot8sm8699290pbc.1.2014.09.27.20.22.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Sep 2014 20:22:16 -0700 (PDT) Sender: Kubilay Kocak Message-ID: <54277EDC.40107@FreeBSD.org> Date: Sun, 28 Sep 2014 13:22:04 +1000 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Tom Everett , freebsd-current@freebsd.org Subject: Re: SOEKRIS kernel config References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 03:22:18 -0000 On 28/09/2014 12:47 PM, Tom Everett wrote: > I see there is no SOEKRIS config on the tree, here > > https://svnweb.freebsd.org/base/head/sys/i386/conf/ > > I have attached one for addition to the tree. > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Thanks Tom This is a good candidate for a Bugzilla Issue, under Base System -> conf so it doesn't get lost in the mail :) -- Koobs From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 06:07:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74F10EF6 for ; Sun, 28 Sep 2014 06:07:32 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DC9A76A for ; Sun, 28 Sep 2014 06:07:31 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XY7dp-002JrT-OF>; Sun, 28 Sep 2014 08:07:29 +0200 Received: from g225003129.adsl.alicedsl.de ([92.225.3.129] helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XY7dp-002V48-M1>; Sun, 28 Sep 2014 08:07:29 +0200 Date: Sun, 28 Sep 2014 08:06:43 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: Re: WiFi 802.11/ac PCIe supported adaptor Message-ID: <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140927222208.GA20243@e-new.0x20.net> References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> <20140927222208.GA20243@e-new.0x20.net> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/ruP7P_mX5gPUHFMV_xqhBfh"; protocol="application/pgp-signature" X-Originating-IP: 92.225.3.129 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 06:07:32 -0000 --Sig_/ruP7P_mX5gPUHFMV_xqhBfh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sun, 28 Sep 2014 00:22:09 +0200 Lars Engels schrieb: > On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote: > >=20 > > I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and = want to > > replace it with an 802.11ac adaptor. > >=20 > > Since I made very bad experiences with CURRENT and support of modest mo= dern hardware > > (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here first. > >=20 > > I found this PCIe adaptor card attractive: > >=20 > > GigaByte Gigabyte GC-WB867D-I > >=20 > > I can not find ad hoc the WLAN chip used on that specific card, but may= be someone has > > experiences with that litte board. >=20 > FreeBSD doensn't support 802.11ac, yet. I'm bitter aware of that. This OS doesn't support the chipsets, even if the= y provide also 11a/g/n. We have at our department now a bunch of Lenovo hardware, with Intels 7260 = chipset. The laptops are now runninmg Ubuntu 14.0X something which obviously supports th= e WiFi chip. I'm the last man standing with FreeBSD on my private Lenovo :-( --Sig_/ruP7P_mX5gPUHFMV_xqhBfh Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUJ6V8AAoJEOgBcD7A/5N8t8QIALZxs2+UqPicdlEe3A3hjriX JnU4OUBrtK9chu184vtzsBMLsn/xp7jicFRthIVVJuj9/0zBnj2aHFVGngl6WNDM UndnldqAGGKqmk7A51o6NgFgoqnH49VDtzgQWba7qztIlCJnljkqVMGiwwo/gJfO KiyhEdzX982smXZrbJJMFIv5uVzIp4HL3stkC+udZ/jOcxJBcEQsQa8iLoNrv9Oj TxoZODtl6tnjjadZVxswBmKc4YR6q5YNXHWmZeLZcbQlmg6gk3PRTui+r87+c/gd PHbH7S2YUlXeMqnhvhELvw/oHPaVtkUNIodax5WwAfp3LLEY2OqEbCkSGf16ts4= =JsXZ -----END PGP SIGNATURE----- --Sig_/ruP7P_mX5gPUHFMV_xqhBfh-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 06:21:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B398613D for ; Sun, 28 Sep 2014 06:21:01 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 996FC8C6 for ; Sun, 28 Sep 2014 06:21:01 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s8S6Kr5Q031112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 27 Sep 2014 23:20:54 -0700 Message-ID: <5427A8C5.1010703@freebsd.org> Date: Sat, 27 Sep 2014 23:20:53 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: WiFi 802.11/ac PCIe supported adaptor References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> <20140927222208.GA20243@e-new.0x20.net> <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVb9B/WwSx49zLr5gbOF0Xc98zHyIC2KyNVtOnNz7qWXUdaSr8N/486reWxsYUmtpPftNXK0PdeTFMnp9m2E8g4yHVRxucELObQ= X-Sonic-ID: C;Fj6GmddG5BGq49FrlZB5Vg== M;8m8EmtdG5BGq49FrlZB5Vg== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 06:21:01 -0000 On 09/27/14 23:06, O. Hartmann wrote: > Am Sun, 28 Sep 2014 00:22:09 +0200 > Lars Engels schrieb: > >> On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote: >>> I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and want to >>> replace it with an 802.11ac adaptor. >>> >>> Since I made very bad experiences with CURRENT and support of modest modern hardware >>> (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here first. >>> >>> I found this PCIe adaptor card attractive: >>> >>> GigaByte Gigabyte GC-WB867D-I >>> >>> I can not find ad hoc the WLAN chip used on that specific card, but maybe someone has >>> experiences with that litte board. >> FreeBSD doensn't support 802.11ac, yet. > I'm bitter aware of that. This OS doesn't support the chipsets, even if they provide also > 11a/g/n. > > We have at our department now a bunch of Lenovo hardware, with Intels 7260 chipset. The > laptops are now runninmg Ubuntu 14.0X something which obviously supports the WiFi chip. > I'm the last man standing with FreeBSD on my private Lenovo :-( This is a serious problem. I'm about ready to install Linux on my laptop as well just to get a usable system. Some kind of funding directed to a willing developer would be hugely valuable for the usability of the operating system on recent hardware. This is probably more important even than Haswell graphics since without a driver, Haswell is merely slow, whereas networking is completely broken. -Nathan From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 06:33:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A4E3D2D8 for ; Sun, 28 Sep 2014 06:33:32 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7663198D for ; Sun, 28 Sep 2014 06:33:32 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id tp5so13346490ieb.10 for ; Sat, 27 Sep 2014 23:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=87Wk2wE87EtYR8HZ6BhQX7T45O3G85Og4m6+Gontn+I=; b=ojWso0uxdBGdsQKRl9LWhimPYG54YsWZcPWfGTSJidWa94fp0x7O9/xZADrCDWztIT +R+NLpGRPuFE4P4T4GAXFLiYSF1tiMAdEN6V4q2Yee8dypmX1agdmzSiLVoK+/L0r+Tb lv4ZchStg+8VIAgx/JxFpXvpAh4xQfPtAdj+hBycmxF93pGKuOQTqQUIR9SZhnA7kbwR JhKwMyHYR1LfG0O1tvHEoLmWK7tLPyvGiCtlXskldN0G4Cnn8piAynpqy0KLS5ijT2MH c2b1D6YKDt8+YglzuCS7YxwYWRKC4gN6G7FfFbrntHrCDf4pKAWX0rpAm7wBWTxgC88l Eeeg== MIME-Version: 1.0 X-Received: by 10.50.4.9 with SMTP id g9mr42597466igg.42.1411886011907; Sat, 27 Sep 2014 23:33:31 -0700 (PDT) Received: by 10.50.122.42 with HTTP; Sat, 27 Sep 2014 23:33:31 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Sep 2014 01:33:31 -0500 Message-ID: Subject: Re: SOEKRIS kernel config From: Scot Hetzel To: Tom Everett Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 06:33:32 -0000 On Sat, Sep 27, 2014 at 9:47 PM, Tom Everett wrote: > I see there is no SOEKRIS config on the tree, here > > https://svnweb.freebsd.org/base/head/sys/i386/conf/ > > I have attached one for addition to the tree. > > Since you only appended a few configuration options to the end of the GENERIC configuration, it would be better to use the include directive in the SOEKRIS config file. This allows changes to be made to the GENERIC configuration, and the SOEKRIS kernel would automatically get those changes. Here's a shorter version of that configuration file: # # SOEKRIS -- Generic Kernel configuration file for FreeBSD/i386 on SOEKRIS # # $FREEBSD include GENERIC ident SOEKRIS # To Make a SOEKRIS Kernel, the next options are needed options CPU_SOEKRIS options CPU_ELAN #options CPU_ELAN_PPS #options CPU_ELAN_XTAL=32768000 options CPU_GEODE # Include TMPFS options TMPFS -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 06:44:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC04F4E9; Sun, 28 Sep 2014 06:44:20 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F8CFAA3; Sun, 28 Sep 2014 06:44:20 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id l13so132465iga.13 for ; Sat, 27 Sep 2014 23:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/VwhyJdScEQXWBJJHwJ3/lMgz0LBNY9n2xBS02Obmtg=; b=Mkq87J+OyVGnyzjChIJIFpKpREs33yCIzbFZo4AOs/d9E2C0devaivbQseVhNj1lLR njMWCuvXU4dZBFqr57VEMTttQlw4Joz+5iMR7l4f15hOGMbfKCapnSsy316zueIO73un 90TSSYdT+3ZQnuZFEzgmWptV7dEt5ZD77de8suvpYVMD+NvDSbdwXBLwGo2AR3vqVl6b IbGUHDmYY7gmrzTSD75WeeNB+v7IxF6uMaOFwRsOmHKMwso2ZUYZY01+y8rw9bFEQ5Rl M16cWXttvKEy3ftz9K5ggDoCOR5XAEDTIAC95FTERLuvA8UJJ/DvGbL3JgegBwhxre/j YLgw== MIME-Version: 1.0 X-Received: by 10.42.91.69 with SMTP id o5mr36736641icm.34.1411886659995; Sat, 27 Sep 2014 23:44:19 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.163.70 with HTTP; Sat, 27 Sep 2014 23:44:19 -0700 (PDT) In-Reply-To: <5427A8C5.1010703@freebsd.org> References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> <20140927222208.GA20243@e-new.0x20.net> <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> <5427A8C5.1010703@freebsd.org> Date: Sat, 27 Sep 2014 23:44:19 -0700 X-Google-Sender-Auth: Rk5BhhTqJ7Cz4KCqSd9wyMFCXDg Message-ID: Subject: Re: WiFi 802.11/ac PCIe supported adaptor From: Kevin Oberman To: Nathan Whitehorn Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 06:44:20 -0000 On Sat, Sep 27, 2014 at 11:20 PM, Nathan Whitehorn wrote: > > On 09/27/14 23:06, O. Hartmann wrote: > >> Am Sun, 28 Sep 2014 00:22:09 +0200 >> Lars Engels schrieb: >> >> On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote: >>> >>>> I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and >>>> want to >>>> replace it with an 802.11ac adaptor. >>>> >>>> Since I made very bad experiences with CURRENT and support of modest >>>> modern hardware >>>> (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here first. >>>> >>>> I found this PCIe adaptor card attractive: >>>> >>>> GigaByte Gigabyte GC-WB867D-I >>>> >>>> I can not find ad hoc the WLAN chip used on that specific card, but >>>> maybe someone has >>>> experiences with that litte board. >>>> >>> FreeBSD doensn't support 802.11ac, yet. >>> >> I'm bitter aware of that. This OS doesn't support the chipsets, even if >> they provide also >> 11a/g/n. >> >> We have at our department now a bunch of Lenovo hardware, with Intels >> 7260 chipset. The >> laptops are now runninmg Ubuntu 14.0X something which obviously supports >> the WiFi chip. >> I'm the last man standing with FreeBSD on my private Lenovo :-( >> > > This is a serious problem. I'm about ready to install Linux on my laptop > as well just to get a usable system. Some kind of funding directed to a > willing developer would be hugely valuable for the usability of the > operating system on recent hardware. This is probably more important even > than Haswell graphics since without a driver, Haswell is merely slow, > whereas networking is completely broken. > -Nathan While I don't yet have need of it and probably won't any time soon, Haswell support is becoming critical. It is getting more and more difficult to get boards with pre-Haswell processors, especially for laptops. It is still pretty easy to get supported WiFi cards for both desktops and laptops. I feel Haswell is getting to be a critical issue. VESA is available for Haswell systems, but it is very slow and too often the BIOS support of VESA is poor. Vendors want text mode for boot and such, but really have little interest in graphics as Intel has good native Windows drivers for them.Still waiting for Lenovo to fix VESA for my old Sandy Bridge laptop. I used VESA, which was badly broken, for almost a year waiting for KMS support, though I did get a recent BIOS update and have not tried VESA on it. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 07:10:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6568BB17; Sun, 28 Sep 2014 07:10:02 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D745FC55; Sun, 28 Sep 2014 07:10:00 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8S79umP007143; Sun, 28 Sep 2014 07:09:56 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: Warner Losh , Adrian Chadd Subject: Re: AHCI after 271145 does not work for me Date: Sun, 28 Sep 2014 09:09:51 +0200 Message-Id: <20140928070425.M39629@aoek.com> In-Reply-To: References: <20140925153725.M29130@beckpeccoz.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 213.37.0.220 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: freebsd-current , Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 07:10:02 -0000 Hi Warner, it's not AHCI, it's something else I am trying to track down. Sorry for thinking it was AHCI, the kernel loops at the latest probe, which happens to be AHCI, but if I remove that from the kernel it loops on something else (usb, clock, whatever). Cheers, On Thu, 25 Sep 2014 17:55:09 -0700, Warner Losh wrote > I’m afraid I have no clue. I’ll need hardware to debug this, since I > don’t have any, or someone that can provide some feedback or even > probe messages with it going off the rails (before/after). > > Warner > > On Sep 25, 2014, at 9:12 AM, Adrian Chadd wrote: > > > Hi! > > > > 271146 was Warner's AHCI probe/attach changes. Maybe he'll have some ideas. :) > > > > Warner? > > > > > > -a > > > > > > On 25 September 2014 08:48, José Pérez Arauzo wrote: > >> Hi, > >> on my Acer Aspire V5, AHCI does not complete device_attach after 271145. > >> > >> Am I the only one experiencing this? Can I help fixing it? Thank you. > >> > >> BR, > >> > >> -- > >> José Pérez Arauzo > >> > >> _______________________________________________ > >> freebsd-current@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 07:34:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C4702EA for ; Sun, 28 Sep 2014 07:34:45 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D0DAE7D for ; Sun, 28 Sep 2014 07:34:44 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8S7Ymc6007809 for ; Sun, 28 Sep 2014 07:34:48 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: FreeBSD Current Subject: What do you use for kernel debugging? Date: Sun, 28 Sep 2014 09:34:43 +0200 Message-Id: <20140928071641.M7664@beckpeccoz.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 213.37.0.220 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 07:34:45 -0000 Hello, I am trying to track down a (deadlock?) issue in CURRENT via DDB. The kernel does not complete hw probes on my Acer V5. I get stuck on apic_isr looping which leads nowhere. So I thought maybe things improve if I debug from another machine. What do you use for kernel debugging? According to the handbook kgdb over serial is a good option, do you agree? I'm on a netbook with no ethernet and no option for firewire: can I have a USB / nullmodem setup to work? I have no old-style uarts hardware anymore, as the handbook suggests... Any idea is welcome before I buy extra hw. I have a USB to serial showing up as /dev/cuaU0, do I need to grab another one and a nullmodem cable or there are better alternatives? Thank you. BR, -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 09:35:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE9B7B00; Sun, 28 Sep 2014 09:35:56 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49528B07; Sun, 28 Sep 2014 09:35:56 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XYAtV-002nYL-Nv>; Sun, 28 Sep 2014 11:35:53 +0200 Received: from g225003129.adsl.alicedsl.de ([92.225.3.129] helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XYAtV-002k6g-Jm>; Sun, 28 Sep 2014 11:35:53 +0200 Date: Sun, 28 Sep 2014 11:35:10 +0200 From: "O. Hartmann" To: Kevin Oberman Subject: Re: WiFi 802.11/ac PCIe supported adaptor Message-ID: <20140928113510.452dc9f0.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> <20140927222208.GA20243@e-new.0x20.net> <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> <5427A8C5.1010703@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/sRNZ25aD4.NocVxRr.Vmq0K"; protocol="application/pgp-signature" X-Originating-IP: 92.225.3.129 X-ZEDAT-Hint: A Cc: FreeBSD Current , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 09:35:56 -0000 --Sig_/sRNZ25aD4.NocVxRr.Vmq0K Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 27 Sep 2014 23:44:19 -0700 Kevin Oberman schrieb: > On Sat, Sep 27, 2014 at 11:20 PM, Nathan Whitehorn > wrote: >=20 > > > > On 09/27/14 23:06, O. Hartmann wrote: > > > >> Am Sun, 28 Sep 2014 00:22:09 +0200 > >> Lars Engels schrieb: > >> > >> On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote: > >>> > >>>> I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card a= nd > >>>> want to > >>>> replace it with an 802.11ac adaptor. > >>>> > >>>> Since I made very bad experiences with CURRENT and support of modest > >>>> modern hardware > >>>> (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here fi= rst. > >>>> > >>>> I found this PCIe adaptor card attractive: > >>>> > >>>> GigaByte Gigabyte GC-WB867D-I > >>>> > >>>> I can not find ad hoc the WLAN chip used on that specific card, but > >>>> maybe someone has > >>>> experiences with that litte board. > >>>> > >>> FreeBSD doensn't support 802.11ac, yet. > >>> > >> I'm bitter aware of that. This OS doesn't support the chipsets, even if > >> they provide also > >> 11a/g/n. > >> > >> We have at our department now a bunch of Lenovo hardware, with Intels > >> 7260 chipset. The > >> laptops are now runninmg Ubuntu 14.0X something which obviously suppor= ts > >> the WiFi chip. > >> I'm the last man standing with FreeBSD on my private Lenovo :-( > >> > > > > This is a serious problem. I'm about ready to install Linux on my laptop > > as well just to get a usable system. Some kind of funding directed to a > > willing developer would be hugely valuable for the usability of the > > operating system on recent hardware. This is probably more important ev= en > > than Haswell graphics since without a driver, Haswell is merely slow, > > whereas networking is completely broken. > > -Nathan >=20 >=20 > While I don't yet have need of it and probably won't any time soon, > Haswell support is becoming critical. It is getting more and more difficu= lt > to get boards with pre-Haswell processors, especially for laptops. It is > still pretty easy to get supported WiFi cards for both desktops and > laptops. I feel Haswell is getting to be a critical issue. >=20 > VESA is available for Haswell systems, but it is very slow and too often > the BIOS support of VESA is poor. Vendors want text mode for boot and suc= h, > but really have little interest in graphics as Intel has good native > Windows drivers for them.Still waiting for Lenovo to fix VESA for my old > Sandy Bridge laptop. I used VESA, which was badly broken, for almost a ye= ar > waiting for KMS support, though I did get a recent BIOS update and have n= ot > tried VESA on it. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Some notes from my side. I have personally a i3-3220 IvyBridge based server with iGPU HD2500, which = doesn't work properly on CURRENT and gets messed up with EFI and vt(). The screen is dar= k after loading i915kms and the reason having a highres console is at hand. This is= two year old hardware! This server is now getting a new XEON CPU (same board, but with a= professional CPU i5-122X v2 with a P4000 iGPU). At another site I work for there are pla= ns obtaining also such toy-XEONs for power consumption reasons and the iGPU play an impo= rtant role here. And those systems are due to government funding for the next couple o= f years definitely NOT outdated hardware from the past, they will be Haswell. So wh= at now? As far as I can say: maintaining a FreeBSD based server system on hardware that ne= eds more than one single compromise is cost-ineffective. I hate to judge things in terms = of cost-effectiveness, but the time, I spent now getting a crap iGPU on my lap= top to work or that on that IvyBridge is unaffordable! The same is now with the laptops. Intels iGPU is getting stronger and stron= ger and combined with their CPUs, there is rarely need for a dedicated GPU. We use = OpenCL a lot, so GPUs are welcome, even in notebooks. But not for FreeBSD, since OpenCL s= eems to be Linux-domain only. Anyway, the new bunch of laptops we order is not the cra= p from yesterday. Since my last Dell had to last for at least four years, I will o= rder top of the line hardware now - and I'm willing to wait for some weeks, two months = with interim solutions until FreeBSD would support the hardware we obtain, but compared = to the past I see chance. Not all of us want Linux, some use PC-BSD, some FreeBSD. The pi= cture changes now. Networking wasn't an issue for me for years, but now, sitting on a pile of = neat new hardware of which FreeBSD can not make any serious use, let me rethink. Luc= kily, The Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSD= s agony I'm able to swap the NIC with a piece of hardware that is supported. But it is = additional cost. I would happily do so - if there wouldn't be Linux support! I tried U= buntu 14 something, and the WiFi NIC was recognized and was fully operational. Even = the iGPU AND the Optimus nVidia GT740M is usable, although Linux has also severe problem= s with the Optimus technology, but somehow there are solutions. But having alternative= s and drivers for months out in a concurrent system like Linux arises some questions the = answeres I can't fathom.=20 Well, I hope that there is some solution out. I found in the FreeBSD Forum = an entry from last year talking about Intel's dual band WiFi NIC 7260's support by the iw= l() driver. I never saw this driver and it is almost a year since the post was made. I do= not need necessarily 802.11ac or 802.11n support, I would be happy having 802.11g su= pport checking emails or checkin/checkout texts and code via WiFi where no wire= is available. And please allow me a final note here. I was always told (or even thaught!) that FreeBSD hasn't the fundings or th= e manpower to solve problems like KMS, driver and so on. I guess several Linux distributi= ons face a similar problem, but somehow the manufactureres emmit drivers or support. I= was aware of that guy that was payed by Intel to develop OpenSource NIC drivers, wasn't = his name Vogel? What happened to him? If FreeBSD is pushed more and more in the back= ground, then it is also due to a bad politics. nVidia, for instance, offers a BLOB for t= heir GPUs. Yeah! But no OpenCL support. AMD offers nothing but promises and their effo= rts regarding opensource drivers is a pity. nVidia "just informed Nouveau" (so the headli= ne at Phoronix, if I'm not wrong), that they now make some new restrictions abou= t their harware. Well, FreeBSD hasn't this problem, we do not haven even xf86-video= -nouveau in the ports due to the lack of functionality in the kernel. The fact is: unde= r these circumstances, FreeBSD is UNUSABLE on some sort of recent hardware and even= opensource drivers are not an option anymore. I can not wait a year until I can use the full potential of the hardware we= purchased, so hopefully I can run FBSD then in a virtual box ontop of Linux as long I nee= d it. --Sig_/sRNZ25aD4.NocVxRr.Vmq0K Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUJ9ZUAAoJEOgBcD7A/5N8tm0H/3EaEYq1zuYICYcs6aZ2K2oG lmOELX0TXZU+8MG9udZ/wV+URg8cVkxGHJiV1mpYEN03kb0bfri1ZjNmGRNQsrvZ dRnfobtiSYBst0vbUj7OYWu/uPopTK424/oE535N2fimM0/qOAXlDOoSUYAG4ZRL jyoJM6AaR9WHn2qxdYt5ijUPtixhf1g4RCTXLLLz+cCEFFAyzv/S/Epe726JUd40 XxPGg2/ILIGGfJpJQoBOYAaS1PFXCQNa1wX2eo8XL77TGRmq0zvYF3tpWcH2dgFK Cyk5V+Dd75wMw2dYQcint7ffz7dhUTiriM1TKDCi2hI1zM8a9NU1zElcDHslYjY= =GHq3 -----END PGP SIGNATURE----- --Sig_/sRNZ25aD4.NocVxRr.Vmq0K-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 09:42:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EC81C48; Sun, 28 Sep 2014 09:42:34 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCA0BBB9; Sun, 28 Sep 2014 09:42:33 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XYAzv-002oPt-Gd>; Sun, 28 Sep 2014 11:42:31 +0200 Received: from g225003129.adsl.alicedsl.de ([92.225.3.129] helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XYAzv-002khd-Bx>; Sun, 28 Sep 2014 11:42:31 +0200 Date: Sun, 28 Sep 2014 11:41:54 +0200 From: "O. Hartmann" To: Koop Mast Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-ID: <20140928114154.5f9c37cb.ohartman@zedat.fu-berlin.de> In-Reply-To: <1411240906.1174.2.camel@rainbow-runner.nl> References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <20140920191530.6b538c62.ohartman@zedat.fu-berlin.de> <20140920201347.0a4b9658.ohartman@zedat.fu-berlin.de> <1411240906.1174.2.camel@rainbow-runner.nl> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/8l=BTlKbX3twIdVly5.h+Q2"; protocol="application/pgp-signature" X-Originating-IP: 92.225.3.129 X-ZEDAT-Hint: A Cc: Warren Block , freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 09:42:34 -0000 --Sig_/8l=BTlKbX3twIdVly5.h+Q2 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 20 Sep 2014 21:21:46 +0200 Koop Mast schrieb: > On Sat, 2014-09-20 at 20:13 +0200, O. Hartmann wrote: > > Am Sat, 20 Sep 2014 19:15:30 +0200 > > "O. Hartmann" schrieb: > >=20 > > > Am Sat, 20 Sep 2014 08:27:27 -0600 (MDT) > > > Warren Block schrieb: > > >=20 > > > > On Sat, 20 Sep 2014, O. Hartmann wrote: > > > >=20 > > > > > Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) > > > > > Warren Block schrieb: > > > > > > > > > >> On Fri, 19 Sep 2014, O. Hartmann wrote: > > > > >> > > > > >>> nVidia's BLOB from port x11/nvidia-driver seems to have problem= s in FreeBSD > > > > >>> 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, o= n Lenovo > > > > >>> ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with inte= grated HD4600 > > > > >>> Intel iGPU and dedicated nVidia GT 740M (Optimus) working corre= ctly. > > > > >> > > > > >> Optimus is supposed to be full Intel graphics plus an Nvidia GPU= . The > > > > >> extra GPU uses the same display memory and can be enabled to spe= ed up > > > > >> the Intel graphics or disabled for power saving. I don't know if > > > > >> versions where the Nvidia section is a full discrete video adapt= er that > > > > >> can be used alone are still called "Optimus". > > > > >> > > > > >> Some Optimus owners have reported being able to use the Intel dr= ivers > > > > >> after disabling the Nvidia GPU in the BIOS or UEFI. If an optio= n to > > > > >> disable the Nvidia GPU is not present, some people have reported= success > > > > >> with an xorg.conf that uses only the intel driver and ignores th= e Nvidia > > > > >> hardware. > > > > > > > > > > Thanks Warren. > > > > > > > > > > But this sounds even more frustrating now. I look around the web = even at > > > > > Lenovo's support forum. Many people report the GT 740M nVidia ada= ptor as a > > > > > discrete adaptor with Optimus technology and everything sounds to= me like it > > > > > can be selected exclusively. What you describes is that I definit= ely need to > > > > > use the HD4600 iGPU on FreeBSD in the first place since the nVidi= a hardware is > > > > > a kind of "appendix" to the HD4600. > > > >=20 > > > > Optimus started out that way, but they might use the same name now = for=20 > > > > models where the additional GPU is a full discrete adapter. > > >=20 > > > I tried to retrieve informations about the settings and implementati= ons in the > > > lenovo E540, but I guess the only answer can be given by developer do= cumentation. I > > > can not figure out how the GPU is attached to the system. The technic= al > > > specifications do not mention the requirement of a iGPU and shared me= mory - as > > > Optimus would require. > > >=20 > > > But extrapolating from that "shit-covering" public relations talking = at nVidia's > > > site I guess the GT 740M is definitely a shared memory solution and r= equires the > > > presence of the iGPU. That would explain why the nvidia BLOB is detec= ting the GPU, > > > but can not find any physical display socket, not even the built-in L= CD. They're > > > maybe wired all throught the Haswell's HD4600 iGPU?=20 > > >=20 > > > >=20 > > > > > Anyway, I also tried to configure X11 as HD4600 only and X11 does= n't work > > > > > properly: it doesn't even start up and loading the "intel" driver= complains > > > > > about a missing device > > > > > - preceeded by a lot of /dev/dri errors. This indicates to me, in= a naiv manner, > > > > > that this HD4600 isn't recodnized by the kernel, either. I do not= see any kind > > > > > of vga0: entry in the kernel log when enabling "Integrated Graphi= cs" only in the > > > > > laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recogni= zed vga0: > > > > > device shows up. > > > >=20 > > > > Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not su= pport=20 > > > > Haswell video yet. > > >=20 > > >=20 > > > I suspected that :-( > > >=20 > > > Thanks anyway, > > >=20 > > > Oliver > >=20 > > Oh, by the way, where is x11-drivers/xf86-video-noveau? I can only find > > x11-drivers/xf86-video-nv, which covers old hardware and it is not appl= icable to the > > GT 740M (complains, rightfully, that the found device isn't supported b= y the "nv" > > driver). > >=20 > > I face a mess here ... :-( >=20 > It was removed, because we missing kernel support for the nouveau > driver. >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Without nouveau driver, FreeBSD people do not have the slightes chance to p= lay with OpenCL/libclc on nVidia's hardware. I'm eager to watch the day when even th= e Radeon driver gets ripped off due to lack of kernel support :-) --Sig_/8l=BTlKbX3twIdVly5.h+Q2 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUJ9fiAAoJEOgBcD7A/5N82wQH+waxUl/NR22er5fqcdSAod4O nB4BcmiCpQ37ihkuhcaDMhBwUHwnzxnVH2H/eKi6DZjqkykbrNb54c/CYlZ5quUY dZoUTykgkYFP50hX9Omm86/EGBEgk1NBh0fiAHITzxLs5AfiEUWhvImKbCqunK7w 41axqgY2p9CHUWYC7e1kFuHxn3UdnXzI7ReLzL01q3wLgLNQl9w4n5sYhTpezdcv pbUFVg+nPFBbekQzr/tfv9CK5v1XHeB28YVV5HwRgLZDKqH1S5P3e1Yu1DAMr/eo xSOUPrAJCL67o56VO3oO0TccVdzvXpwHqDR8Og2tbAfRAO0sDLQtHarysrqnIdk= =wasw -----END PGP SIGNATURE----- --Sig_/8l=BTlKbX3twIdVly5.h+Q2-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 09:45:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3FB86D8D for ; Sun, 28 Sep 2014 09:45:33 +0000 (UTC) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECE96BCC for ; Sun, 28 Sep 2014 09:45:32 +0000 (UTC) Received: from fortune.joker.local (180-198-225-68.nagoya1.commufa.jp [180.198.225.68]) (authenticated bits=0) by dec.sakura.ne.jp (8.14.3/8.14.2/[SAKURA-WEB]/20080708) with ESMTP id s8S9jOJW026066 for ; Sun, 28 Sep 2014 18:45:24 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 28 Sep 2014 18:45:23 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: WiFi 802.11/ac PCIe supported adaptor Message-Id: <20140928184523.3c7e4c9e664c685687e145fe@dec.sakura.ne.jp> In-Reply-To: <5427A8C5.1010703@freebsd.org> References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> <20140927222208.GA20243@e-new.0x20.net> <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> <5427A8C5.1010703@freebsd.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 09:45:33 -0000 These should be good job for The FreeBSD FOUNDATION, like former Diablo JDK/JRE case. At least, as far as I remember, adrian@ noted a patent issue (RSU) in porting Intel 7260AC.[1] If I remember correctly, there was anothe thread in another ML, but currently I missed it. Maybe -arch ML? In these cases, The FreeBSD FOUNDATION would be good legal body for licence contracts / agreements with patent holder(s). [1] https://lists.freebsd.org/pipermail/freebsd-wireless/2014-June/004748.html On Sat, 27 Sep 2014 23:20:53 -0700 Nathan Whitehorn wrote: > > On 09/27/14 23:06, O. Hartmann wrote: > > Am Sun, 28 Sep 2014 00:22:09 +0200 > > Lars Engels schrieb: > > > >> On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote: > >>> I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and want to > >>> replace it with an 802.11ac adaptor. > >>> > >>> Since I made very bad experiences with CURRENT and support of modest modern hardware > >>> (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here first. > >>> > >>> I found this PCIe adaptor card attractive: > >>> > >>> GigaByte Gigabyte GC-WB867D-I > >>> > >>> I can not find ad hoc the WLAN chip used on that specific card, but maybe someone has > >>> experiences with that litte board. > >> FreeBSD doensn't support 802.11ac, yet. > > I'm bitter aware of that. This OS doesn't support the chipsets, even if they provide also > > 11a/g/n. > > > > We have at our department now a bunch of Lenovo hardware, with Intels 7260 chipset. The > > laptops are now runninmg Ubuntu 14.0X something which obviously supports the WiFi chip. > > I'm the last man standing with FreeBSD on my private Lenovo :-( > > This is a serious problem. I'm about ready to install Linux on my laptop > as well just to get a usable system. Some kind of funding directed to a > willing developer would be hugely valuable for the usability of the > operating system on recent hardware. This is probably more important > even than Haswell graphics since without a driver, Haswell is merely > slow, whereas networking is completely broken. > -Nathan > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Tomoaki AOKI junchoon@dec.sakura.ne.jp From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 09:59:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B74A611E; Sun, 28 Sep 2014 09:59:06 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43507CAA; Sun, 28 Sep 2014 09:59:05 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XYBFw-002rWs-B9>; Sun, 28 Sep 2014 11:59:04 +0200 Received: from g225003129.adsl.alicedsl.de ([92.225.3.129] helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XYBFw-002mKD-6s>; Sun, 28 Sep 2014 11:59:04 +0200 Date: Sun, 28 Sep 2014 11:58:27 +0200 From: "O. Hartmann" To: Kevin Oberman Subject: Re: WiFi 802.11/ac PCIe supported adaptor Message-ID: <20140928115827.2c6bafe7.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> <20140927222208.GA20243@e-new.0x20.net> <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> <5427A8C5.1010703@freebsd.org> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/TtT_l/FcAXgIDSSxGbUtG2Y"; protocol="application/pgp-signature" X-Originating-IP: 92.225.3.129 X-ZEDAT-Hint: A Cc: FreeBSD Current , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 09:59:06 -0000 --Sig_/TtT_l/FcAXgIDSSxGbUtG2Y Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 27 Sep 2014 23:44:19 -0700 Kevin Oberman schrieb: > On Sat, Sep 27, 2014 at 11:20 PM, Nathan Whitehorn > wrote: >=20 > > > > On 09/27/14 23:06, O. Hartmann wrote: > > > >> Am Sun, 28 Sep 2014 00:22:09 +0200 > >> Lars Engels schrieb: > >> > >> On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote: > >>> > >>>> I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card a= nd > >>>> want to > >>>> replace it with an 802.11ac adaptor. > >>>> > >>>> Since I made very bad experiences with CURRENT and support of modest > >>>> modern hardware > >>>> (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here fi= rst. > >>>> > >>>> I found this PCIe adaptor card attractive: > >>>> > >>>> GigaByte Gigabyte GC-WB867D-I > >>>> > >>>> I can not find ad hoc the WLAN chip used on that specific card, but > >>>> maybe someone has > >>>> experiences with that litte board. > >>>> > >>> FreeBSD doensn't support 802.11ac, yet. > >>> > >> I'm bitter aware of that. This OS doesn't support the chipsets, even if > >> they provide also > >> 11a/g/n. > >> > >> We have at our department now a bunch of Lenovo hardware, with Intels > >> 7260 chipset. The > >> laptops are now runninmg Ubuntu 14.0X something which obviously suppor= ts > >> the WiFi chip. > >> I'm the last man standing with FreeBSD on my private Lenovo :-( > >> > > > > This is a serious problem. I'm about ready to install Linux on my laptop > > as well just to get a usable system. Some kind of funding directed to a > > willing developer would be hugely valuable for the usability of the > > operating system on recent hardware. This is probably more important ev= en > > than Haswell graphics since without a driver, Haswell is merely slow, > > whereas networking is completely broken. > > -Nathan >=20 >=20 > While I don't yet have need of it and probably won't any time soon, > Haswell support is becoming critical. It is getting more and more difficu= lt > to get boards with pre-Haswell processors, especially for laptops. It is > still pretty easy to get supported WiFi cards for both desktops and > laptops. I feel Haswell is getting to be a critical issue. I use the xf86-video-scfb driver, VESA driver doesn' coop with the resoluti= on of my display (called Full HD, 1980x1080 pixel). VESA complains about not know re= solution when starting. The SCFB is unusable. The i5-4200M CPU has enough stamina to do well, but w= hen it comes to video/desktop/graphics under load, the graphics is rendered unusable.=20 The laptop is not productive and an expensive heap of plastic, silica and m= etal with FreeBSD that way. >=20 > VESA is available for Haswell systems, but it is very slow and too often > the BIOS support of VESA is poor. Vendors want text mode for boot and suc= h, > but really have little interest in graphics as Intel has good native > Windows drivers for them.Still waiting for Lenovo to fix VESA for my old > Sandy Bridge laptop. I used VESA, which was badly broken, for almost a ye= ar > waiting for KMS support, though I did get a recent BIOS update and have n= ot > tried VESA on it. > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --Sig_/TtT_l/FcAXgIDSSxGbUtG2Y Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUJ9vDAAoJEOgBcD7A/5N8WZoH/1xt216QcoJchXED0B48lz+B tcYRLGJoZAefCLDDKN55EGhsDsz4hBKGldxSYknk0WggxvNJd6NTOrPqbw0LmhTk Vvi+FfuWlIVyReKBvGikt0H0sEawh286FBSK6SJNVVmmpdBE1ZPhgZ8mOjI83gTZ PtC2HbJCRlhIBCXVtNmdyhJn2zLEYhueCrMefWuVt+snERIoeqB5lwipoJSwS8Ld xzNGtkvZa2kMvyHBzhWQfUsdhMU7vBrwRFUOt6Boa5w+0NzLCjIecbwgbnhWj7pL q1uNr4IQYSKVFfvFIPJyUsATCfiKIjDVpd6lHE8NSZn/I+MpRCyC7cDIcGLfJBY= =Hrgg -----END PGP SIGNATURE----- --Sig_/TtT_l/FcAXgIDSSxGbUtG2Y-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 10:05:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 077B82C8; Sun, 28 Sep 2014 10:05:41 +0000 (UTC) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65E59D75; Sun, 28 Sep 2014 10:05:40 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id x48so351535wes.41 for ; Sun, 28 Sep 2014 03:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dbzZBcNQx3w3u9R62s9d/kzy1KMsPhmlMn+O43BgsdU=; b=v6sFxGeR1aN/0dpiqg922KJ9FI6d59es3tz9elKJuVRHrF6xg3vk9u0xaoR/hdOEEU /DPf5q7WT0OsRh4xvjfnfXmlGC7YO3JsySvMxgSpeOJuntxL9NylvCkkFd8Gifucot4Q npMZ3vRItv2FNRY7FCfhZJO81eeskt7iJ80dRDGVlwZ3pvOo6ETGhMeVUDPRqCjF3QxS s+2+9FNLGTNwZOh3hDaHnhprd1IFpIb9C93TVwY/A5yjSzDyw7yeTve/FjlSqYLLLtSK IshB0FGgtKgLU+G8r9buC2+CJ5rnOoLV6lJKLCiGcW7h6Eyc4p8HpfaKPUA6KrG+i6dE GpLg== X-Received: by 10.180.231.9 with SMTP id tc9mr37240716wic.58.1411898738629; Sun, 28 Sep 2014 03:05:38 -0700 (PDT) Received: from ?IPv6:2001:470:1f15:b1f:e564:306f:b705:1b46? ([2001:470:1f15:b1f:e564:306f:b705:1b46]) by mx.google.com with ESMTPSA id hy9sm12026720wjb.27.2014.09.28.03.05.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Sep 2014 03:05:37 -0700 (PDT) Message-ID: <5427DD70.5080906@gmail.com> Date: Sun, 28 Sep 2014 12:05:36 +0200 From: =?windows-1252?Q?Jan_Kokem=FCller?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "O. Hartmann" Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <20140920191530.6b538c62.ohartman@zedat.fu-berlin.de> <20140920201347.0a4b9658.ohartman@zedat.fu-berlin.de> <1411240906.1174.2.camel@rainbow-runner.nl> <20140928114154.5f9c37cb.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140928114154.5f9c37cb.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 10:05:41 -0000 On 28.09.2014 11:41, O. Hartmann wrote: > Without nouveau driver, FreeBSD people do not have the slightes chance to play with > OpenCL/libclc on nVidia's hardware. Some time in the past it was possible to run CUDA/OpenCL Linux binaries with the Nvidia driver in Linux emulation mode on FreeBSD: https://web.archive.org/web/20121015180221/http://blogs.freebsdish.org/jhb/2010/07/20/using-cuda-with-the-native-freebsdamd64-nvidia-driver Not sure if that still works though. From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 10:08:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 414BE4A1 for ; Sun, 28 Sep 2014 10:08:43 +0000 (UTC) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E314DDAB for ; Sun, 28 Sep 2014 10:08:42 +0000 (UTC) Received: from fortune.joker.local (180-198-225-68.nagoya1.commufa.jp [180.198.225.68]) (authenticated bits=0) by dec.sakura.ne.jp (8.14.3/8.14.2/[SAKURA-WEB]/20080708) with ESMTP id s8SA8fdB035497 for ; Sun, 28 Sep 2014 19:08:41 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sun, 28 Sep 2014 19:08:40 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: WiFi 802.11/ac PCIe supported adaptor Message-Id: <20140928190840.05dfa7df79129be87217915c@dec.sakura.ne.jp> In-Reply-To: <20140928184523.3c7e4c9e664c685687e145fe@dec.sakura.ne.jp> References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> <20140927222208.GA20243@e-new.0x20.net> <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> <5427A8C5.1010703@freebsd.org> <20140928184523.3c7e4c9e664c685687e145fe@dec.sakura.ne.jp> Organization: Junchoon corps X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 10:08:43 -0000 Grr... Not RSU, but RCU. And found these threads in -arch ML. https://lists.freebsd.org/pipermail/freebsd-arch/2014-June/015413.html https://lists.freebsd.org/pipermail/freebsd-arch/2014-June/015419.html On Sun, 28 Sep 2014 18:45:23 +0900 Tomoaki AOKI wrote: > These should be good job for The FreeBSD FOUNDATION, like former Diablo > JDK/JRE case. > > At least, as far as I remember, adrian@ noted a patent issue (RSU) in > porting Intel 7260AC.[1] > If I remember correctly, there was anothe thread in another ML, but > currently I missed it. Maybe -arch ML? > > In these cases, The FreeBSD FOUNDATION would be good legal body for > licence contracts / agreements with patent holder(s). > > > [1] > https://lists.freebsd.org/pipermail/freebsd-wireless/2014-June/004748.html > > > On Sat, 27 Sep 2014 23:20:53 -0700 > Nathan Whitehorn wrote: > > > > On 09/27/14 23:06, O. Hartmann wrote: > > > Am Sun, 28 Sep 2014 00:22:09 +0200 > > > Lars Engels schrieb: > > > > > >> On Sat, Sep 27, 2014 at 02:38:30PM +0200, O. Hartmann wrote: > > >>> I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and want to > > >>> replace it with an 802.11ac adaptor. > > >>> > > >>> Since I made very bad experiences with CURRENT and support of modest modern hardware > > >>> (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here first. > > >>> > > >>> I found this PCIe adaptor card attractive: > > >>> > > >>> GigaByte Gigabyte GC-WB867D-I > > >>> > > >>> I can not find ad hoc the WLAN chip used on that specific card, but maybe someone has > > >>> experiences with that litte board. > > >> FreeBSD doensn't support 802.11ac, yet. > > > I'm bitter aware of that. This OS doesn't support the chipsets, even if they provide also > > > 11a/g/n. > > > > > > We have at our department now a bunch of Lenovo hardware, with Intels 7260 chipset. The > > > laptops are now runninmg Ubuntu 14.0X something which obviously supports the WiFi chip. > > > I'm the last man standing with FreeBSD on my private Lenovo :-( > > > > This is a serious problem. I'm about ready to install Linux on my laptop > > as well just to get a usable system. Some kind of funding directed to a > > willing developer would be hugely valuable for the usability of the > > operating system on recent hardware. This is probably more important > > even than Haswell graphics since without a driver, Haswell is merely > > slow, whereas networking is completely broken. > > -Nathan > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > -- > Tomoaki AOKI junchoon@dec.sakura.ne.jp > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Tomoaki AOKI junchoon@dec.sakura.ne.jp From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 11:00:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C468D26; Sun, 28 Sep 2014 11:00:53 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03781234; Sun, 28 Sep 2014 11:00:52 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XYCDi-0031Sh-IR>; Sun, 28 Sep 2014 13:00:50 +0200 Received: from g225003129.adsl.alicedsl.de ([92.225.3.129] helo=hermann.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XYCDi-002sml-F8>; Sun, 28 Sep 2014 13:00:50 +0200 Date: Sun, 28 Sep 2014 13:00:13 +0200 From: "O. Hartmann" To: Jan =?ISO-8859-1?Q?Kokem=FCller?= Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT Message-ID: <20140928130013.64cd74c9.ohartman@zedat.fu-berlin.de> In-Reply-To: <5427DD70.5080906@gmail.com> References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <20140920191530.6b538c62.ohartman@zedat.fu-berlin.de> <20140920201347.0a4b9658.ohartman@zedat.fu-berlin.de> <1411240906.1174.2.camel@rainbow-runner.nl> <20140928114154.5f9c37cb.ohartman@zedat.fu-berlin.de> <5427DD70.5080906@gmail.com> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/c68npe7HNxe.H.xotDG8heg"; protocol="application/pgp-signature" X-Originating-IP: 92.225.3.129 X-ZEDAT-Hint: A Cc: freebsd-x11@freebsd.org, FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 11:00:53 -0000 --Sig_/c68npe7HNxe.H.xotDG8heg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Am Sun, 28 Sep 2014 12:05:36 +0200 Jan Kokem=FCller schrieb: >=20 > On 28.09.2014 11:41, O. Hartmann wrote: > > Without nouveau driver, FreeBSD people do not have the slightes chance = to play with > > OpenCL/libclc on nVidia's hardware. >=20 > Some time in the past it was possible to run CUDA/OpenCL Linux binaries=20 > with the Nvidia driver in Linux emulation mode on FreeBSD: >=20 > https://web.archive.org/web/20121015180221/http://blogs.freebsdish.org/jh= b/2010/07/20/using-cuda-with-the-native-freebsdamd64-nvidia-driver >=20 > Not sure if that still works though. Well, I went through this stuff that time and from the date, you can see it= s four years in the past! There was also thast promising thing from Pathscale, HMPC ast pro= mising thing from Pathscale, HMPC or similar, now OpenACC. But at the end it was a "drea= m-bubble". And as far as I know: even the Linuxulator is ways behind the recent develo= pment and still 32Bit (ancient, so to speak). I do not want myself having lots of out= dated hard- and software running and developing on outdated platforms. And it is even worse: some new technology utilizing LLVM, libCLC, most rece= nt MESA libs and the most recent opensource graphics driver provide rudimentary OpenCL s= upport for the GPU - but as I stated in the thread concerning the missing WiFi Intel 7260 = support - FreeBSD hasn't even the xf86-video-nouveau driver anymore which is supposed= to work best in that scenario. I had very longish discussions in 2010 about this subject - from a naiv non= -developer point of view. I was always told, FreeBSD is an OS for servers and we all k= now, that servers do not rely on graphics hardware that much as it is important for g= raphics workstations and not at least desktop machines. But what we faced five years ago in science regarding the rapid development= of OpenCL and GPGPU showed me very ckearly that GPU hardware is becoming dramatically imp= ortant. With AMD providing powerful iGPUs and now Intel doing the same, number crunching= isn't the domain of physicists and numerical geeks anymore, GEGL starts to incorporat= e OpenCL and GIMP is about to utilize the GPU as well. BLENDER is utilizing CUDA in Linu= x and I guess OpenCL is also on the way. And if this isn't convincing: I read about cloud= computing with massively parallelized TESLA backends, a typical domain of dump and un= exciting hardware and their operating systems. And guess what? The key is obviously = the support of the graphical functionality, not necessarily the X11 desktop it self. The project that time in 2010, where we were supposed and inclined to use F= reeBSD as the development platform for a highly parallelized application for planetary sc= ience imaging was then based on OpenSUSE and Ubuntu Linux and OpenCL. From a simple naive= point of view, I can not express deeply enough how excited I was when I saw, how fas= t the combination of CPUs and GPUs using OpenCL coding could be. What was done in= an expensive and professional manner on expensive hardware was developed and tested on c= heaper "gaming riggs" and even on those platforms the boost was tremendous. But not with F= reeBSD! All Linux. I think FreeBSD will find its niche in the embedded networking hardware mar= ket as long as it still has the faster network stack. But since the Linux folks started to= attack this domain in a disgusting PR-ish way, I doubt that even this will last long. O= r FreeBSD will show its power with colourless databases. One of the reasons why FreeBSD is still on top of the list of the OSes is t= he fact of its deep ZFS incorporation - as Matthew Dillon once said: it saved FreeBSD's as= s. Well, Dillon developed then HAMMER and showed once again, that the effords in the= BSD field are spread all over the area and thinning out as times passes. For FreeBSD, the= day when Linux will have its ZFS in-kernel will be devastating - I guess. --Sig_/c68npe7HNxe.H.xotDG8heg Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUJ+o9AAoJEOgBcD7A/5N8TZgH/3lQk1aeswwb1Km2W5GMvNFN syEScHCmLW2FQWoxDTwdn3bhHFmUzXxzqViwTXmJ/NRpWeS2LzK4vHglvEfxFGvp ThrN/0FHw11UqCm1fkHv+zPO+YxnjrGxA3FKPkpixpTsoFKR5NK8sUW1RRLjO25d k6D9nOx0QVvq6dyxZDq0ApC49JvA2Btd8NgObXnb1J4tjsaQPcyB0YjmdG8AqjSq IAZfjxhoEX5uUvFCUjURomwbakc8e2vJYEiXKowEyj2CNb07l6TaGBRFySFsaM95 Te6zOoGU31OSjO2mqwQzBkWLhqDYLMUN+35Hb1CVJWKt70ZKSs9+62W+O4lTPUo= =YGtX -----END PGP SIGNATURE----- --Sig_/c68npe7HNxe.H.xotDG8heg-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 14:57:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C45FE2F5; Sun, 28 Sep 2014 14:57:57 +0000 (UTC) Received: from mail-gw14.york.ac.uk (mail-gw14.york.ac.uk [144.32.129.164]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D30ABEF; Sun, 28 Sep 2014 14:57:57 +0000 (UTC) Received: from ury.york.ac.uk ([144.32.64.162]:63518) by mail-gw14.york.ac.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XYFv1-0003NL-Ed; Sun, 28 Sep 2014 15:57:47 +0100 Date: Sun, 28 Sep 2014 15:57:47 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: "O. Hartmann" Subject: Re: WiFi 802.11/ac PCIe supported adaptor In-Reply-To: <20140928113510.452dc9f0.ohartman@zedat.fu-berlin.de> Message-ID: References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> <20140927222208.GA20243@e-new.0x20.net> <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> <5427A8C5.1010703@freebsd.org> <20140928113510.452dc9f0.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Kevin Oberman , FreeBSD Current , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 14:57:57 -0000 On Sun, 28 Sep 2014, O. Hartmann wrote: > Am Sat, 27 Sep 2014 23:44:19 -0700 > Kevin Oberman schrieb: > > > On Sat, Sep 27, 2014 at 11:20 PM, Nathan Whitehorn > > wrote: > > > > > On 09/27/14 23:06, O. Hartmann wrote: > > > > > >> Am Sun, 28 Sep 2014 00:22:09 +0200 > > >> Lars Engels schrieb: > > >> > > >>> FreeBSD doensn't support 802.11ac, yet. > > >>> > > >> I'm bitter aware of that. This OS doesn't support the chipsets, even if > > >> they provide also > > >> 11a/g/n. As Lars says, we don't yet support anything 11ac, either hardware/driver wise, or in the 802.11 stack. I am aware of people working on support for the 7260, though I suspect a working driver will be some time away. It will also only support a/b/g and maybe n to begin with - we are quite a way from having 11ac support in the stack. > > >> We have at our department now a bunch of Lenovo hardware, with Intels > > >> 7260 chipset. The > > >> laptops are now runninmg Ubuntu 14.0X something which obviously supports > > >> the WiFi chip. > > >> I'm the last man standing with FreeBSD on my private Lenovo :-( > > >> > > > > > > This is a serious problem. I'm about ready to install Linux on my laptop > > > as well just to get a usable system. Some kind of funding directed to a > > > willing developer would be hugely valuable for the usability of the > > > operating system on recent hardware. This is probably more important even > > > than Haswell graphics since without a driver, Haswell is merely slow, > > > whereas networking is completely broken. Unfortunately, funding is just half the problem - we also need to find a developer capable of doing the work. The Intel 3160 and 7260 will likely require a whole new driver - almost no code can be shared between it and the iwn(4) driver. Please understand though that getting a driver for the Intel 11ac devices is seen as a big priority. > Some notes from my side. > > I have personally a i3-3220 IvyBridge based server with iGPU HD2500, which doesn't work > properly on CURRENT and gets messed up with EFI and vt(). The screen is dark after > loading i915kms and the reason having a highres console is at hand. This is two year old > hardware! This server is now getting a new XEON CPU (same board, but with a professional Can you point me to a thread or PR about this? > Networking wasn't an issue for me for years, but now, sitting on a pile of neat new > hardware of which FreeBSD can not make any serious use, let me rethink. Luckily, The > Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs agony I'm > able to swap the NIC with a piece of hardware that is supported. But it is additional Unfortunately, many Lenovo laptops lock the BIOS down in such a way that they won't boot without the NIC they were shipped with :( > I was always told (or even thaught!) that FreeBSD hasn't the fundings or the manpower to > solve problems like KMS, driver and so on. I guess several Linux distributions face a > similar problem, but somehow the manufactureres emmit drivers or support. I was aware of > that guy that was payed by Intel to develop OpenSource NIC drivers, wasn't his name > Vogel? What happened to him? If FreeBSD is pushed more and more in the background, then Jack Vogel still supports wired Intel NIC drivers for us, and other Intel staff support other hardware such as their new storage controllers. > it is also due to a bad politics. nVidia, for instance, offers a BLOB for their GPUs. > Yeah! But no OpenCL support. AMD offers nothing but promises and their efforts regarding > opensource drivers is a pity. nVidia "just informed Nouveau" (so the headline at > Phoronix, if I'm not wrong), that they now make some new restrictions about their > harware. Well, FreeBSD hasn't this problem, we do not haven even xf86-video-nouveau in > the ports due to the lack of functionality in the kernel. The fact is: under these > circumstances, FreeBSD is UNUSABLE on some sort of recent hardware and even opensource > drivers are not an option anymore. I'm not hugely knowledgeable on the state of drivers, but: - We have new drivers for the Radeon stuff, in head and 10.1. - nVidia provide FreeBSD drivers for FreeBSD. I understand that part of the reason we don't have OpenCL support is because they don't know there is a demand for it. - I have no idea what functionality we lack for Nouveau, is that documented anywhere? Thanks, Gavin From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 14:59:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D38AA7AC for ; Sun, 28 Sep 2014 14:59:09 +0000 (UTC) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0E85E38 for ; Sun, 28 Sep 2014 14:59:08 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id a13so1989578igq.13 for ; Sun, 28 Sep 2014 07:59:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/luLYfNIzrfHDCnypJ41Sosd40JcETJunAiadGADBvk=; b=VnSWgufKWgneX+Jva8qfgzvJxGJZFrfApBl3s+vZnvlWSN2mfMMZQhBFHXp//O50Me qib03wTUeemCbHi5owFQlVIw5bn+o5DBaEbtB6z1FSyi5MBXi5np+TVsvpJvj2BgLBo0 wml0Bvy01AGYqwu5RiJLi44eIRgaFyU5F/W59NLlHhBwwQNU2Uj1Wa5q31aIFEZujz/f qkn5Tx2FXXHIVp/bruxxtweWvBMG/CBmd8oZ3XOq4Y7C4PwKmEtsSA2oSQ4lnmWJduko iYu8Tobo7lGeS0NyUcgrEYgFRFo1CC7s+9+g7V7dbDWrMPKnmzH2UFABy7tLJ8gya5Ir +19A== X-Gm-Message-State: ALoCoQkHWAdHlBQfBB4bJu3hd3bOitUKk5PYm0HLBiV28az34QSGf/tZ06X4qy8WOjOANiiSLUOd MIME-Version: 1.0 X-Received: by 10.42.92.129 with SMTP id t1mr39444722icm.59.1411916347991; Sun, 28 Sep 2014 07:59:07 -0700 (PDT) Received: by 10.64.13.33 with HTTP; Sun, 28 Sep 2014 07:59:07 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Sep 2014 08:59:07 -0600 Message-ID: Subject: Re: SOEKRIS kernel config From: Tom Everett To: Scot Hetzel Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 14:59:09 -0000 That's a great idea. I'll give it a try and get back to the list. On Sun, Sep 28, 2014 at 12:33 AM, Scot Hetzel wrote: > On Sat, Sep 27, 2014 at 9:47 PM, Tom Everett wrote: > > I see there is no SOEKRIS config on the tree, here > > > > https://svnweb.freebsd.org/base/head/sys/i386/conf/ > > > > I have attached one for addition to the tree. > > > > > > Since you only appended a few configuration options to the end of the > GENERIC configuration, it would be better to use the include directive > in the SOEKRIS config file. This allows changes to be made to the > GENERIC configuration, and the SOEKRIS kernel would automatically get > those changes. Here's a shorter version of that configuration file: > > > # > # SOEKRIS -- Generic Kernel configuration file for FreeBSD/i386 on SOEKRIS > # > # $FREEBSD > > include GENERIC > > ident SOEKRIS > > # To Make a SOEKRIS Kernel, the next options are needed > options CPU_SOEKRIS > options CPU_ELAN > #options CPU_ELAN_PPS > #options CPU_ELAN_XTAL=32768000 > options CPU_GEODE > > # Include TMPFS > options TMPFS > > > -- > DISCLAIMER: > > No electrons were maimed while sending this message. Only slightly bruised. > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 15:52:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6BD8263 for ; Sun, 28 Sep 2014 15:52:16 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 503775F9 for ; Sun, 28 Sep 2014 15:52:16 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j5WZl0hCRz1DNl for ; Sun, 28 Sep 2014 11:52:15 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j5WZk1lSGz1C1j for ; Sun, 28 Sep 2014 11:52:14 -0400 (EDT) Message-ID: <201409281152140359.008FD377@smtp.24cl.home> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Sun, 28 Sep 2014 11:52:14 -0400 From: "Mike." To: freebsd-current@freebsd.org Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 15:52:16 -0000 I'm starting to look at FreeBSD 11-current to see what's coming soon. I have an older notebook that I use for test environments for purposes such as this. Unfortunately, the notebook won't boot up from the install CD, there's a loop it cannot seem to get out of. Details are: - The install CD was made from this image: FreeBSD-11.0-CURRENT-i386-20140918-r271779-disc1 - The dmesg for the notebook is at the end of this message. The dmesg was captured with FreeBSD 10.0. In the dmesg, you can see the following lines: (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata1:0:1:0): CAM status: Command timeout (aprobe0:ata1:0:1:0): Error 5, Retry was blocked run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata1:0:1:0): CAM status: Command timeout (aprobe0:ata1:0:1:0): Error 5, Retry was blocked which, while slowing down the boot process drastically, still allowed the boot process to run to successful completion. - When I try to boot using the FreeBSD 11-current install CD, that loop seems to go on ad infinitum, or at least for the 5 minutes until I gave up. I cannot post a dmesg from that boot-up because I never got to a prompt. However, I did take a couple of pictures of the offending screens. They are here: http://archive.mgm51.com/cache/fbsd-11-current-01.jpg http://archive.mgm51.com/cache/fbsd-11-current-02.jpg The first image shows the start of the looping, and the second shows the continuation. While this notebook is used only for testing, it is important to me in that aspect. How can I get around this looping issue? Please let me know if there's any additional info you need. Thanks. And now, the dmesg... Copyright (c) 1992-2014 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 10.0-RELEASE-p8 #1 r271323: Wed Sep 10 20:25:45 EDT 2014 root@a31pf.245l.home:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.60-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Family = 0xf Model = 0x2 Stepping = 4 Features=0x3febf9ff real memory = 1073741824 (1024 MB) avail memory = 1029230592 (981 MB) kbd1 at kbdmux0 random: initialized acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xe8000000-0xefffffff,0xd0100000-0xd010ffff irq 11 at device 0.0 on pci1 vgapci0: Boot video device uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 usbus2 on uhci2 pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: mem 0x50000000-0x50000fff irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0x50100000-0x50100fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci2: at device 0.2 (no driver attached) fxp0: port 0x8000-0x803f mem 0xd0200000-0xd0200fff irq 11 at device 8.0 on pci2 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow fxp0: Ethernet address: 00:0e:9b:2c:d3:f6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff irq 11 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe000 0-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. acpi_perf0: on cpu0 p4tcc0: on cpu0 Timecounters tick every 1.000 msec random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 ugen2.1: at usbus2 uhub0: on usbus2 ugen1.1: at usbus1 uhub1: on usbus1 ugen0.1: at usbus0 uhub2: on usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ath0: irq 11 at device 0.0 on cardbus1 ath0: AR5212 mac 5.6 RF5112 phy 4.1 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0036 (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata1:0:1:0): CAM status: Command timeout (aprobe0:ata1:0:1:0): Error 5, Retry was blocked run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata1:0:1:0): CAM status: Command timeout (aprobe0:ata1:0:1:0): Error 5, Retry was blocked ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-6 device ada0: Serial Number MPC412Y4G6J1AE ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Trying to mount root from ufs:/dev/ada0p2 [rw]... wlan0: Ethernet address: 00:04:e2:b6:d4:d6 From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 15:53:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BFDE3E0 for ; Sun, 28 Sep 2014 15:53:07 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2F0E610 for ; Sun, 28 Sep 2014 15:53:06 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j5Wbj604wz1DNl for ; Sun, 28 Sep 2014 11:53:05 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j5Wbj0Z9bz1C1j for ; Sun, 28 Sep 2014 11:53:05 -0400 (EDT) Message-ID: <201409281153050191.00909A0F@smtp.24cl.home> References: <201409281152140359.008FD377@smtp.24cl.home> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Sun, 28 Sep 2014 11:53:05 -0400 From: "Mike." To: freebsd-current@freebsd.org Subject: Looping during boot-up process in FreeBSD-11 current Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 15:53:07 -0000 I'm starting to look at FreeBSD 11-current to see what's coming soon. I have an older notebook that I use for test environments for purposes such as this. Unfortunately, the notebook won't boot up from the install CD, there's a loop it cannot seem to get out of. Details are: - The install CD was made from this image: FreeBSD-11.0-CURRENT-i386-20140918-r271779-disc1 - The dmesg for the notebook is at the end of this message. The dmesg was captured with FreeBSD 10.0. In the dmesg, you can see the following lines: (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata1:0:1:0): CAM status: Command timeout (aprobe0:ata1:0:1:0): Error 5, Retry was blocked run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata1:0:1:0): CAM status: Command timeout (aprobe0:ata1:0:1:0): Error 5, Retry was blocked which, while slowing down the boot process drastically, still allowed the boot process to run to successful completion. - When I try to boot using the FreeBSD 11-current install CD, that loop seems to go on ad infinitum, or at least for the 5 minutes until I gave up. I cannot post a dmesg from that boot-up because I never got to a prompt. However, I did take a couple of pictures of the offending screens. They are here: http://archive.mgm51.com/cache/fbsd-11-current-01.jpg http://archive.mgm51.com/cache/fbsd-11-current-02.jpg The first image shows the start of the looping, and the second shows the continuation. While this notebook is used only for testing, it is important to me in that aspect. How can I get around this looping issue? Please let me know if there's any additional info you need. Thanks. And now, the dmesg... Copyright (c) 1992-2014 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 10.0-RELEASE-p8 #1 r271323: Wed Sep 10 20:25:45 EDT 2014 root@a31pf.245l.home:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.60-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Family = 0xf Model = 0x2 Stepping = 4 Features=0x3febf9ff real memory = 1073741824 (1024 MB) avail memory = 1029230592 (981 MB) kbd1 at kbdmux0 random: initialized acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xe8000000-0xefffffff,0xd0100000-0xd010ffff irq 11 at device 0.0 on pci1 vgapci0: Boot video device uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 usbus2 on uhci2 pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: mem 0x50000000-0x50000fff irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0x50100000-0x50100fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci2: at device 0.2 (no driver attached) fxp0: port 0x8000-0x803f mem 0xd0200000-0xd0200fff irq 11 at device 8.0 on pci2 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow fxp0: Ethernet address: 00:0e:9b:2c:d3:f6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff irq 11 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe000 0-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. acpi_perf0: on cpu0 p4tcc0: on cpu0 Timecounters tick every 1.000 msec random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 ugen2.1: at usbus2 uhub0: on usbus2 ugen1.1: at usbus1 uhub1: on usbus1 ugen0.1: at usbus0 uhub2: on usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ath0: irq 11 at device 0.0 on cardbus1 ath0: AR5212 mac 5.6 RF5112 phy 4.1 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0036 (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata1:0:1:0): CAM status: Command timeout (aprobe0:ata1:0:1:0): Error 5, Retry was blocked run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata1:0:1:0): CAM status: Command timeout (aprobe0:ata1:0:1:0): Error 5, Retry was blocked ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-6 device ada0: Serial Number MPC412Y4G6J1AE ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Trying to mount root from ufs:/dev/ada0p2 [rw]... wlan0: Ethernet address: 00:04:e2:b6:d4:d6 From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 16:01:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47F9C62C for ; Sun, 28 Sep 2014 16:01:59 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id C8DA974D for ; Sun, 28 Sep 2014 16:01:58 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 2691320E7088F; Sun, 28 Sep 2014 16:01:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 0FE5620E7088B; Sun, 28 Sep 2014 16:01:54 +0000 (UTC) Message-ID: <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> From: "Steven Hartland" To: "Mike." , References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> Subject: Re: Looping during boot-up process in FreeBSD-11 current Date: Sun, 28 Sep 2014 17:01:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 16:01:59 -0000 The only recent ATAPI change I recall is 270327, does it still occur if you revert that? Regards Steve ----- Original Message ----- From: "Mike." > > > I'm starting to look at FreeBSD 11-current to see what's coming soon. > I have an older notebook that I use for test environments for > purposes such as this. Unfortunately, the notebook won't boot up > from the install CD, there's a loop it cannot seem to get out of. > > > > Details are: > > - The install CD was made from this image: > FreeBSD-11.0-CURRENT-i386-20140918-r271779-disc1 > > - The dmesg for the notebook is at the end of this message. The > dmesg was captured with FreeBSD 10.0. In the dmesg, you can see the > following lines: > > (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 > 00 00 00 > (aprobe0:ata1:0:1:0): CAM status: Command timeout > (aprobe0:ata1:0:1:0): Error 5, Retry was blocked > run_interrupt_driven_hooks: still waiting after 60 seconds for > xpt_config > (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 > 00 00 00 > (aprobe0:ata1:0:1:0): CAM status: Command timeout > (aprobe0:ata1:0:1:0): Error 5, Retry was blocked > > > which, while slowing down the boot process drastically, still allowed > the boot process to run to successful completion. > > > - When I try to boot using the FreeBSD 11-current install CD, that > loop seems to go on ad infinitum, or at least for the 5 minutes until > I gave up. I cannot post a dmesg from that boot-up because I never > got to a prompt. However, I did take a couple of pictures of the > offending screens. They are here: > http://archive.mgm51.com/cache/fbsd-11-current-01.jpg > http://archive.mgm51.com/cache/fbsd-11-current-02.jpg > The first image shows the start of the looping, and the second shows > the continuation. > > > While this notebook is used only for testing, it is important to me > in that aspect. How can I get around this looping issue? > > Please let me know if there's any additional info you need. > > Thanks. > > > > > > And now, the dmesg... > > Copyright (c) 1992-2014 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 10.0-RELEASE-p8 #1 r271323: Wed Sep 10 20:25:45 EDT 2014 > root@a31pf.245l.home:/usr/obj/usr/src/sys/GENERIC i386 > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.60-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0xf24 Family = 0xf Model = 0x2 > Stepping = 4 > Features=0x3febf9ff MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM> > real memory = 1073741824 (1024 MB) > avail memory = 1029230592 (981 MB) > kbd1 at kbdmux0 > random: initialized > acpi0: on motherboard > acpi_ec0: port 0x62,0x66 on > acpi0 > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 3ff00000 (3) failed > cpu0: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on > acpi0 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x3000-0x30ff mem > 0xe8000000-0xefffffff,0xd0100000-0xd010ffff irq 11 at device 0.0 on > pci1 > vgapci0: Boot video device > uhci0: port > 0x1800-0x181f irq 11 at device 29.0 on pci0 > usbus0 on uhci0 > uhci1: port > 0x1820-0x183f irq 11 at device 29.1 on pci0 > usbus1 on uhci1 > uhci2: port > 0x1840-0x185f irq 11 at device 29.2 on pci0 > usbus2 on uhci2 > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > cbb0: mem 0x50000000-0x50000fff irq 11 > at device 0.0 on pci2 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb1: mem 0x50100000-0x50100fff irq 11 > at device 0.1 on pci2 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > pci2: at device 0.2 (no driver attached) > fxp0: port 0x8000-0x803f > mem 0xd0200000-0xd0200fff irq 11 at device 8.0 on pci2 > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, > auto-flow > fxp0: Ethernet address: 00:0e:9b:2c:d3:f6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on > pci0 > ata0: at channel 0 on atapci0 > ata1: at channel 1 on atapci0 > pci0: at device 31.3 (no driver attached) > pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff irq 11 > at device 31.5 on pci0 > pcm0: > pci0: at device 31.6 (no driver > attached) > acpi_tz0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > battery0: on acpi0 > acpi_acad0: on acpi0 > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe000 > 0-0xeffff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > ppc0: parallel port not found. > acpi_perf0: on cpu0 > p4tcc0: on cpu0 > Timecounters tick every 1.000 msec > random: unblocking device. > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > ugen2.1: at usbus2 > uhub0: on > usbus2 > ugen1.1: at usbus1 > uhub1: on > usbus1 > ugen0.1: at usbus0 > uhub2: on > usbus0 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > ath0: irq 11 at device 0.0 on cardbus1 > ath0: AR5212 mac 5.6 RF5112 phy 4.1 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0036 > (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 > 00 00 00 > (aprobe0:ata1:0:1:0): CAM status: Command timeout > (aprobe0:ata1:0:1:0): Error 5, Retry was blocked > run_interrupt_driven_hooks: still waiting after 60 seconds for > xpt_config > (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 > 00 00 00 > (aprobe0:ata1:0:1:0): CAM status: Command timeout > (aprobe0:ata1:0:1:0): Error 5, Retry was blocked > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-6 device > ada0: Serial Number MPC412Y4G6J1AE > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad0 > cd0 at ata1 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not > present - tray closed > Trying to mount root from ufs:/dev/ada0p2 [rw]... > wlan0: Ethernet address: 00:04:e2:b6:d4:d6 > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 16:43:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8A06F7E for ; Sun, 28 Sep 2014 16:43:39 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75F15ADD for ; Sun, 28 Sep 2014 16:43:39 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j5Xk02brWz1DPH for ; Sun, 28 Sep 2014 12:43:36 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j5Xjy36lRz1C1t for ; Sun, 28 Sep 2014 12:43:34 -0400 (EDT) Message-ID: <201409281243340608.00BED3B6@smtp.24cl.home> In-Reply-To: <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Sun, 28 Sep 2014 12:43:34 -0400 From: "Mike." To: freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 16:43:39 -0000 On 9/28/2014 at 5:01 PM Steven Hartland wrote: |The only recent ATAPI change I recall is 270327, does it still occur |if you revert that? | ============= OK, I'll download the 11-current source. Then revert 270327 https://svnweb.freebsd.org/base/head/sys/cam/ata/ata_xpt.c?r1=270327& r2=270326&pathrev=270327 Recompile the system And try to boot. I'll post the results in a couple of days (full system compiles take a while on this notebook). (unless someone has a 11-current ISO snapshot from before 270327?) From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 17:25:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1CEB39A8 for ; Sun, 28 Sep 2014 17:25:10 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id D478CE2A for ; Sun, 28 Sep 2014 17:25:09 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 1F5FA20E7088F; Sun, 28 Sep 2014 17:25:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 7C82920E7088B; Sun, 28 Sep 2014 17:25:05 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Mike." , References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409281243340608.00BED3B6@smtp.24cl.home> Subject: Re: Looping during boot-up process in FreeBSD-11 current Date: Sun, 28 Sep 2014 18:25:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 17:25:10 -0000 You'll only need a new kernel and if you cut down to modules / drivers you need then that shouldn't take too long. Regards Steve ----- Original Message ----- From: "Mike." To: Sent: Sunday, September 28, 2014 5:43 PM Subject: Re: Looping during boot-up process in FreeBSD-11 current > > > On 9/28/2014 at 5:01 PM Steven Hartland wrote: > > |The only recent ATAPI change I recall is 270327, does it still occur > |if you revert that? > | > ============= > > > OK, I'll download the 11-current source. > > Then revert 270327 > https://svnweb.freebsd.org/base/head/sys/cam/ata/ata_xpt.c?r1=270327& > r2=270326&pathrev=270327 > > Recompile the system > > And try to boot. > > > I'll post the results in a couple of days (full system compiles take > a while on this notebook). > > (unless someone has a 11-current ISO snapshot from before 270327?) > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 18:06:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B4CB0524 for ; Sun, 28 Sep 2014 18:06:08 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 81A9F1F5 for ; Sun, 28 Sep 2014 18:06:08 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j5ZYC06sxz1DNj for ; Sun, 28 Sep 2014 14:06:07 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j5ZYB0zRXz1C2d for ; Sun, 28 Sep 2014 14:06:06 -0400 (EDT) Message-ID: <201409281406060388.010A628E@smtp.24cl.home> In-Reply-To: References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409281243340608.00BED3B6@smtp.24cl.home> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Sun, 28 Sep 2014 14:06:06 -0400 From: "Mike." To: freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 18:06:08 -0000 On 9/28/2014 at 6:25 PM Steven Hartland wrote: |You'll only need a new kernel and if you cut down to modules / drivers |you need then that shouldn't take too long. | ============= Buildworld is running now. So it will be running overnight, and should be finished by the time I can get to it again tomorrow. Thanks. From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 19:59:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E40EA42B for ; Sun, 28 Sep 2014 19:59:48 +0000 (UTC) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83F3AE6A for ; Sun, 28 Sep 2014 19:59:48 +0000 (UTC) X-AuditID: 12074425-f79e46d000002583-86-5428677fe15b Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 25.EE.09603.F7768245; Sun, 28 Sep 2014 15:54:39 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s8SJsdAU012383; Sun, 28 Sep 2014 15:54:39 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8SJsblI032717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 28 Sep 2014 15:54:38 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8SJsagK028118; Sun, 28 Sep 2014 15:54:36 -0400 (EDT) Date: Sun, 28 Sep 2014 15:54:36 -0400 (EDT) From: Benjamin Kaduk To: =?ISO-8859-15?Q?Jos=E9_P=E9rez_Arauzo?= Subject: Re: What do you use for kernel debugging? In-Reply-To: <20140928071641.M7664@beckpeccoz.com> Message-ID: References: <20140928071641.M7664@beckpeccoz.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hTV1q1P1wgx+DnZyKL79BRmizlvPjA5 MHlMfRfkMePTfJYApigum5TUnMyy1CJ9uwSujPsbF7EXrOOqmLjmGVsD4wKOLkZODgkBE4m/ v5+yQthiEhfurWfrYuTiEBKYzSTRdv4KM4SzkVHixJqFUJlDTBI7fhxignAaGCVOHV3IDNLP IqAtsXL7FTYQm01ARWLmm41gtoiAlcTplU8YQWxmAUOJ7sOHwGxhASOJG5/+sHQxcnBwAtkH jieDhHkFHCX+rpoAViIEVP6o+w3YGFEBHYnV+6ewQNQISpyc+QSslVkgUKL1VOkERsFZSDKz EDKzwPaqSzQ+OMsGYWtL3L/ZxraAkWUVo2xKbpVubmJmTnFqsm5xcmJeXmqRroVebmaJXmpK 6SZGUFCzu6juYJxwSOkQowAHoxIP74eN6iFCrIllxZW5hxglOZiURHmXpmqECPEl5adUZiQW Z8QXleakFh9ilOBgVhLhVXgNVM6bklhZlVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1CCYr w8GhJMFrlgY0VLAoNT21Ii0zpwQhzcTBCTKcB2g4A0gNb3FBYm5xZjpE/hSjLse6zm/9TEIs efl5qVLivHEgRQIgRRmleXBzYMnoFaM40FvCvLwgVTzARAY36RXQEiagJWkbQD4oLklESEk1 MNpyh9xqtbZ+LaywdZFK86PCN0pe68/Iu57k/PzGeukLUYvdy8oZfQ08j92SFg9Mkv2Xczji 2Z24njeHG6yd1rNO/7FufkUyxyvn8wHxj7lDl/6TFnN4nPIiRnH3zPsznv76WWzM75vI76p7 8dnBViOdz3974g1iWFQYFx5umjPxkqJnf1VIghJLcUaioRZzUXEiAAPiCsQhAwAA Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 19:59:49 -0000 On Sun, 28 Sep 2014, Jos=C3=A9 P=C3=A9rez Arauzo wrote: > Hello, > I am trying to track down a (deadlock?) issue in CURRENT via DDB. The ker= nel does > not complete hw probes on my Acer V5. > > I get stuck on apic_isr looping which leads nowhere. > > So I thought maybe things improve if I debug from another machine. > > > What do you use for kernel debugging? According to the handbook kgdb over= serial > is a good option, do you agree? I'm on a netbook with no ethernet and no = option > for firewire: can I have a USB / nullmodem setup to work? You cannot. > I have no old-style uarts hardware anymore, as the handbook suggests... > > Any idea is welcome before I buy extra hw. I have a USB to serial showing= up as > /dev/cuaU0, do I need to grab another one and a nullmodem cable or there = are better > alternatives? Thank you. I'm not sure that there are alternatives at all, unfortunately. You may be reduced to debugging-via-printf. -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 20:09:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38FC36C7 for ; Sun, 28 Sep 2014 20:09:44 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0583BF3C for ; Sun, 28 Sep 2014 20:09:43 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id x19so15905311ier.15 for ; Sun, 28 Sep 2014 13:09:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=at6ykSeHFNut1usn809NslpM3b0R2tFy/XOYvwF0v3g=; b=lho9zhGzlINPCM0G4qgmo5M6kD5/eLZUR9e4kdK4K16o6kmBlMv/YVe+8MytVaP2ce WT0++jORm0OxSieuW9pvJwIx6aSFDVGHrYwW8BXkcijq24ORv8gHaAHfugiQ57+rvmq4 Epwv6+PYOl+uPTitNVCgW+x3hHyb+YFJWSd7Gc9us12LvOZMz+ODwKsAVCdAb6lQmPG7 rM0VidxRFfrrnhTYR5BQwvmvHljLfommvE7svVUatts2mS7j+daaVK45NnlcxWlOHt0H cN+akQNF48RSgk8Ig1YekQJLeKDf7DAIour355QbVCZtKVVPiyhgyPhPHQ6w1WgxFP73 iy1A== X-Gm-Message-State: ALoCoQnjmCrkEVh2ZyhlPx8Z1TnZLEVk5Y23MLNcNHtecPjQbG6wVcotZM8N7txVkhD5qXZ4LJVb MIME-Version: 1.0 X-Received: by 10.50.109.228 with SMTP id hv4mr30258744igb.13.1411934976907; Sun, 28 Sep 2014 13:09:36 -0700 (PDT) Received: by 10.64.13.33 with HTTP; Sun, 28 Sep 2014 13:09:36 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Sep 2014 14:09:36 -0600 Message-ID: Subject: Re: SOEKRIS kernel config From: Tom Everett To: Scot Hetzel Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 20:09:44 -0000 Bugzilla ID is *194003 * On Sun, Sep 28, 2014 at 8:59 AM, Tom Everett wrote: > That's a great idea. I'll give it a try and get back to the list. > > > On Sun, Sep 28, 2014 at 12:33 AM, Scot Hetzel wrote: > >> On Sat, Sep 27, 2014 at 9:47 PM, Tom Everett wrote: >> > I see there is no SOEKRIS config on the tree, here >> > >> > https://svnweb.freebsd.org/base/head/sys/i386/conf/ >> > >> > I have attached one for addition to the tree. >> > >> > >> >> Since you only appended a few configuration options to the end of the >> GENERIC configuration, it would be better to use the include directive >> in the SOEKRIS config file. This allows changes to be made to the >> GENERIC configuration, and the SOEKRIS kernel would automatically get >> those changes. Here's a shorter version of that configuration file: >> >> >> # >> # SOEKRIS -- Generic Kernel configuration file for FreeBSD/i386 on SOEKRIS >> # >> # $FREEBSD >> >> include GENERIC >> >> ident SOEKRIS >> >> # To Make a SOEKRIS Kernel, the next options are needed >> options CPU_SOEKRIS >> options CPU_ELAN >> #options CPU_ELAN_PPS >> #options CPU_ELAN_XTAL=32768000 >> options CPU_GEODE >> >> # Include TMPFS >> options TMPFS >> >> >> -- >> DISCLAIMER: >> >> No electrons were maimed while sending this message. Only slightly >> bruised. >> > > > > -- > A better world shall emerge based on faith and understanding - Douglas > MacArthur > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 20:22:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91B8E9B7 for ; Sun, 28 Sep 2014 20:22:54 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 55A42132 for ; Sun, 28 Sep 2014 20:22:53 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id A017620E7088F; Sun, 28 Sep 2014 20:13:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id BA08820E70885; Sun, 28 Sep 2014 20:13:51 +0000 (UTC) Message-ID: <58FFAD0C5E82494D9C52C891FE3A2728@multiplay.co.uk> From: "Steven Hartland" To: "Benjamin Kaduk" , =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauzo?= References: <20140928071641.M7664@beckpeccoz.com> Subject: Re: What do you use for kernel debugging? Date: Sun, 28 Sep 2014 21:13:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 20:22:54 -0000 ----- Original Message ----- From: "Benjamin Kaduk" To: "José Pérez Arauzo" Cc: "FreeBSD Current" Sent: Sunday, September 28, 2014 8:54 PM Subject: Re: What do you use for kernel debugging? > On Sun, 28 Sep 2014, José Pérez Arauzo wrote: > >> Hello, >> I am trying to track down a (deadlock?) issue in CURRENT via DDB. The kernel does >> not complete hw probes on my Acer V5. >> >> I get stuck on apic_isr looping which leads nowhere. >> >> So I thought maybe things improve if I debug from another machine. >> >> >> What do you use for kernel debugging? According to the handbook kgdb over serial >> is a good option, do you agree? I'm on a netbook with no ethernet and no option >> for firewire: can I have a USB / nullmodem setup to work? > > You cannot. > >> I have no old-style uarts hardware anymore, as the handbook suggests... >> >> Any idea is welcome before I buy extra hw. I have a USB to serial showing up as >> /dev/cuaU0, do I need to grab another one and a nullmodem cable or there are better >> alternatives? Thank you. > > I'm not sure that there are alternatives at all, unfortunately. > > You may be reduced to debugging-via-printf. dtrace can also be quite invaluable. Regards Steve From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 20:38:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 174D9E87 for ; Sun, 28 Sep 2014 20:38:28 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC2B62EB for ; Sun, 28 Sep 2014 20:38:27 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id et14so1397228pad.31 for ; Sun, 28 Sep 2014 13:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mEpSxacnES6BvMniDRnL+WQOlntPbdu3eHZkTr/Z5YQ=; b=T5eBC9HhGdSJE4QBcz4/cwzXk5gEWp93o+s7db+IoMM2kbRbJZnuXDYKOXXFTkP7KD wN2betMQUv/LhUx+BWtmgvH1F829ljCpQsI3Tzh3s01p4PwuRkQKJfdGu6qf/5iDX1HN 3YtZkVWf0wMsVusdj2Ns7xc12rzR3XK+X7QzYiM1lXtFpPpUfPNr0KKyRRS4a6sW0c+n UOoJAK8qH95sW9XUstelDlZlHk2ZbLvSs0CXAkMjbZRhEfCh+bgWd0q0PawftPUfH7FG XeMfVXpRzdyAg6p3csBECWXhW0GT6MIj0rbZqz7UYmvLqXXJMKcOQazF+2wxmaZhY+p0 AqrA== X-Received: by 10.66.141.197 with SMTP id rq5mr53702461pab.124.1411936707510; Sun, 28 Sep 2014 13:38:27 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:b9b6:ae1a:c5f8:5a4? ([2601:8:ab80:7d6:b9b6:ae1a:c5f8:5a4]) by mx.google.com with ESMTPSA id dg9sm10431784pdb.50.2014.09.28.13.38.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Sep 2014 13:38:26 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C461D4E5-545F-48E9-A3D9-85D515C522E7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: What do you use for kernel debugging? From: Garrett Cooper In-Reply-To: <20140928071641.M7664@beckpeccoz.com> Date: Sun, 28 Sep 2014 13:38:24 -0700 Message-Id: <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> References: <20140928071641.M7664@beckpeccoz.com> To: =?iso-8859-1?Q?Jos=E9_P=E9rez_Arauzo?= X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 20:38:28 -0000 --Apple-Mail=_C461D4E5-545F-48E9-A3D9-85D515C522E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 28, 2014, at 0:34, Jos=E9 P=E9rez Arauzo wrote: > Hello, > I am trying to track down a (deadlock?) issue in CURRENT via DDB. The = kernel does > not complete hw probes on my Acer V5. >=20 > I get stuck on apic_isr looping which leads nowhere. >=20 > So I thought maybe things improve if I debug from another machine. >=20 >=20 > What do you use for kernel debugging? According to the handbook kgdb = over serial > is a good option, do you agree? I'm on a netbook with no ethernet and = no option > for firewire: can I have a USB / nullmodem setup to work? >=20 > I have no old-style uarts hardware anymore, as the handbook = suggests... >=20 > Any idea is welcome before I buy extra hw. I have a USB to serial = showing up as > /dev/cuaU0, do I need to grab another one and a nullmodem cable or = there are better > alternatives? Thank you. There was some discussion recently about this on an internal list. = Unfortunately no, there isn=92t a usable way, but there were some = interesting viable methods that came up (which haven=92t been = implemented): ethernet/sound/xHCI. Your best bet, as others have noted, is to use boot -d, use WITNESS to = spot locking issues, dtrace to isolate which section of code there are = problems, and finally use one of the DEBUG options noted in = /sys/conf/NOTES and /sys//conf/NOTES . Hope that helps! -Garrett --Apple-Mail=_C461D4E5-545F-48E9-A3D9-85D515C522E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUKHHAAAoJEMZr5QU6S73easYIAKdOGhZ3SvgF6FsauvKm1+Qs VTjc6GM52jQ8ph8Xnk51ETnCcCszZOyfG/5pwU9ldh3hiJNLYj1TKuIpxOEtmhX2 u9cyM9fWXRK/VIycFtsdoP3HvEwPRG2SFOUQO5VxVVvwEoGEWD+Jez/7KYm1tadO X4bkKnnXb9wYTz+pJNhXwjdX2Yxfgx+mi8iS2/7YxQgytC89wScoPLrsIEjyGENW iiSSJbbKLduOBvSJWO3aWIeEXItsbR2wJlbMtRPb4sJPk+MN5j9g2b9SElKzBi6m 2I3ZyOAEH0EJJDGsZNJkNZQzQHeFyldaJSBYchVIaKDbPQHiQeqFFxfVkCjJJ/E= =cDlc -----END PGP SIGNATURE----- --Apple-Mail=_C461D4E5-545F-48E9-A3D9-85D515C522E7-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 20:50:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECBBE2BE; Sun, 28 Sep 2014 20:50:05 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 940613FB; Sun, 28 Sep 2014 20:50:05 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s8SKo3EA052909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 28 Sep 2014 14:50:03 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s8SKo2IV052906; Sun, 28 Sep 2014 14:50:02 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 28 Sep 2014 14:50:02 -0600 (MDT) From: Warren Block To: Gavin Atkinson Subject: Re: WiFi 802.11/ac PCIe supported adaptor In-Reply-To: Message-ID: References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> <20140927222208.GA20243@e-new.0x20.net> <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> <5427A8C5.1010703@freebsd.org> <20140928113510.452dc9f0.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 28 Sep 2014 14:50:03 -0600 (MDT) Cc: FreeBSD Current , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 20:50:06 -0000 On Sun, 28 Sep 2014, Gavin Atkinson wrote: > On Sun, 28 Sep 2014, O. Hartmann wrote: >> Networking wasn't an issue for me for years, but now, sitting on a pile of neat new >> hardware of which FreeBSD can not make any serious use, let me rethink. Luckily, The >> Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs agony I'm >> able to swap the NIC with a piece of hardware that is supported. But it is additional > > Unfortunately, many Lenovo laptops lock the BIOS down in such a way that > they won't boot without the NIC they were shipped with :( Well, or a short list of approved Lenovo-branded cards. In the past, Lenovo (or IBM) has supplied Atheros cards. The trick will be finding that list and identifying the chipsets on each. There are also unofficial BIOS modifications to remove the limits. >> it is also due to a bad politics. nVidia, for instance, offers a BLOB for their GPUs. >> Yeah! But no OpenCL support. AMD offers nothing but promises and their efforts regarding >> opensource drivers is a pity. AMD has actually supported the open Radeon driver, both with programming information and (I think) employing developers to work on it. From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 21:34:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 902EC8B0; Sun, 28 Sep 2014 21:34:02 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD8B0B63; Sun, 28 Sep 2014 21:34:01 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id x13so11529141wgg.4 for ; Sun, 28 Sep 2014 14:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3P01TPLbvt2RdZ7Svv3YRi+x9io6ENAi7jWwTXXn/lw=; b=oRgmYllyJ4FI0nwNUJ1So3WS0bIqJkQOMngxO3Nwan70wJeK2PeQdK/m7zrvw0TFT6 v/NBDNWe0+SQYbdyxHUsArHp7C4//Tczb7wvds8t64T5z9L4eKYahTY1JhMIk+hL4tO5 FLTPut3w3WZQPDQKSuKTgDWe0wZaqM1rm1KjEf1uwCfnJ9tBi4W+43Uv/Lc0pegbwvLy l6rfufrYW23z7VgxsdXb0uJ0Z43J9XwB2GxRivB4ZvEoViMx99xAlxyN80t+qy9FrINQ nIHe+IwMnxgfOwVN6o5rqK0WFIwS21dDzkR9XmPtNacCdTyGG6gvei6UmTiwq2FypQf9 xxqQ== MIME-Version: 1.0 X-Received: by 10.180.187.83 with SMTP id fq19mr60379791wic.59.1411940040105; Sun, 28 Sep 2014 14:34:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sun, 28 Sep 2014 14:34:00 -0700 (PDT) In-Reply-To: References: <20140927143830.1d25968f.ohartman@zedat.fu-berlin.de> <20140927222208.GA20243@e-new.0x20.net> <20140928080643.1b5c991b.ohartman@zedat.fu-berlin.de> <5427A8C5.1010703@freebsd.org> <20140928113510.452dc9f0.ohartman@zedat.fu-berlin.de> Date: Sun, 28 Sep 2014 14:34:00 -0700 X-Google-Sender-Auth: ixr_U-aeYFAY6W0unYQVvIC_6vs Message-ID: Subject: Re: WiFi 802.11/ac PCIe supported adaptor From: Adrian Chadd To: Gavin Atkinson Content-Type: text/plain; charset=UTF-8 Cc: Kevin Oberman , FreeBSD Current , "O. Hartmann" , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 21:34:02 -0000 Hi, It's not a high priority in FreeBSD. It's just "highly desired." There's a difference. Someone paid someone to do a 7260 driver for OpenBSD. It'll work, like iwn worked, but it's missing a lot of the 11n and 11ac bits that are going to be crucial to do 11ac stack bring-up on FreeBSD. So, if this is really high priority in FreeBSD, someone would've paid someone to port the Linux driver to FreeBSD. But right now all there really is right now is "desire", not "priority." -a On 28 September 2014 07:57, Gavin Atkinson wrote: > On Sun, 28 Sep 2014, O. Hartmann wrote: >> Am Sat, 27 Sep 2014 23:44:19 -0700 >> Kevin Oberman schrieb: >> >> > On Sat, Sep 27, 2014 at 11:20 PM, Nathan Whitehorn >> > wrote: >> > >> > > On 09/27/14 23:06, O. Hartmann wrote: >> > > >> > >> Am Sun, 28 Sep 2014 00:22:09 +0200 >> > >> Lars Engels schrieb: >> > >> >> > >>> FreeBSD doensn't support 802.11ac, yet. >> > >>> >> > >> I'm bitter aware of that. This OS doesn't support the chipsets, even if >> > >> they provide also >> > >> 11a/g/n. > > As Lars says, we don't yet support anything 11ac, either hardware/driver > wise, or in the 802.11 stack. > > I am aware of people working on support for the 7260, though I suspect a > working driver will be some time away. It will also only support a/b/g > and maybe n to begin with - we are quite a way from having 11ac support in > the stack. > >> > >> We have at our department now a bunch of Lenovo hardware, with Intels >> > >> 7260 chipset. The >> > >> laptops are now runninmg Ubuntu 14.0X something which obviously supports >> > >> the WiFi chip. >> > >> I'm the last man standing with FreeBSD on my private Lenovo :-( >> > >> >> > > >> > > This is a serious problem. I'm about ready to install Linux on my laptop >> > > as well just to get a usable system. Some kind of funding directed to a >> > > willing developer would be hugely valuable for the usability of the >> > > operating system on recent hardware. This is probably more important even >> > > than Haswell graphics since without a driver, Haswell is merely slow, >> > > whereas networking is completely broken. > > Unfortunately, funding is just half the problem - we also need to find a > developer capable of doing the work. The Intel 3160 and 7260 will likely > require a whole new driver - almost no code can be shared between it and > the iwn(4) driver. > > Please understand though that getting a driver for the Intel 11ac devices > is seen as a big priority. > >> Some notes from my side. >> >> I have personally a i3-3220 IvyBridge based server with iGPU HD2500, which doesn't work >> properly on CURRENT and gets messed up with EFI and vt(). The screen is dark after >> loading i915kms and the reason having a highres console is at hand. This is two year old >> hardware! This server is now getting a new XEON CPU (same board, but with a professional > > Can you point me to a thread or PR about this? > >> Networking wasn't an issue for me for years, but now, sitting on a pile of neat new >> hardware of which FreeBSD can not make any serious use, let me rethink. Luckily, The >> Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs agony I'm >> able to swap the NIC with a piece of hardware that is supported. But it is additional > > Unfortunately, many Lenovo laptops lock the BIOS down in such a way that > they won't boot without the NIC they were shipped with :( > >> I was always told (or even thaught!) that FreeBSD hasn't the fundings or the manpower to >> solve problems like KMS, driver and so on. I guess several Linux distributions face a >> similar problem, but somehow the manufactureres emmit drivers or support. I was aware of >> that guy that was payed by Intel to develop OpenSource NIC drivers, wasn't his name >> Vogel? What happened to him? If FreeBSD is pushed more and more in the background, then > > Jack Vogel still supports wired Intel NIC drivers for us, and other Intel > staff support other hardware such as their new storage controllers. > >> it is also due to a bad politics. nVidia, for instance, offers a BLOB for their GPUs. >> Yeah! But no OpenCL support. AMD offers nothing but promises and their efforts regarding >> opensource drivers is a pity. nVidia "just informed Nouveau" (so the headline at >> Phoronix, if I'm not wrong), that they now make some new restrictions about their >> harware. Well, FreeBSD hasn't this problem, we do not haven even xf86-video-nouveau in >> the ports due to the lack of functionality in the kernel. The fact is: under these >> circumstances, FreeBSD is UNUSABLE on some sort of recent hardware and even opensource >> drivers are not an option anymore. > > I'm not hugely knowledgeable on the state of drivers, but: > - We have new drivers for the Radeon stuff, in head and 10.1. > - nVidia provide FreeBSD drivers for FreeBSD. I understand that part of > the reason we don't have OpenCL support is because they don't know > there is a demand for it. > - I have no idea what functionality we lack for Nouveau, is that > documented anywhere? > > Thanks, > > Gavin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 21:37:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62756A27; Sun, 28 Sep 2014 21:37:50 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 306B8B88; Sun, 28 Sep 2014 21:37:50 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8SLc3Uo068251; Sun, 28 Sep 2014 14:38:09 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8SLbwbK068250; Sun, 28 Sep 2014 14:37:58 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sun, 28 Sep 2014 14:37:58 -0700 (PDT) Message-ID: <7b0a119ebc4d8d7813f92c0f94aba8d8.authenticated@ultimatedns.net> Date: Sun, 28 Sep 2014 14:37:58 -0700 (PDT) Subject: Mesa-9: configure: error: C compiler cannot create executables From: "Chris H" To: "freebsd current" , "freebsd stable" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 21:37:50 -0000 Greetings, A recent install of RELENG_9, followed by a build|install world|kernel. Returns the following error when attempting an make install of x11/xorg-minimal ===> Configuring for dri-9.1.7_5,2 configure: loading site script /usr/ports/Templates/config.site checking build system type... amd64-portbld-freebsd9.3 checking host system type... amd64-portbld-freebsd9.3 checking target system type... amd64-portbld-freebsd9.3 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p checking for gawk... (cached) /usr/bin/awk checking whether gmake sets $(MAKE)... yes checking whether gmake supports nested variables... yes checking for style of include used by gmake... GNU checking for gcc... clang checking whether the C compiler works... no configure: error: in `/usr/ports/graphics/dri/work/Mesa-9.1.7': configure: error: C compiler cannot create executables See `config.log' for more details ===> Script "configure" failed unexpectedly. Please report the problem to x11@FreeBSD.org [maintainer] and attach the "/usr/ports/graphics/dri/work/Mesa-9.1.7/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea). *** [do-configure] Error code 1 Any thoughts on how to overcome this issue? Relevant info: # svn info /usr/src Path: /usr/src Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/9 Relative URL: ^/stable/9 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 272203 Node Kind: directory Schedule: normal Last Changed Author: thomas Last Changed Rev: 272184 Last Changed Date: 2014-09-26 12:13:13 -0700 (Fri, 26 Sep 2014) svn info /usr/ports Path: /usr/ports Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 369380 Node Kind: directory Schedule: normal Last Changed Author: mva Last Changed Rev: 369380 Last Changed Date: 2014-09-27 01:34:11 -0700 (Sat, 27 Sep 2014) FreeBSD demon 9.3-STABLE FreeBSD 9.3-STABLE #0 r272203: Sat Sep 27 15:49:55 PDT 2014 root@demon:/usr/obj/usr/src/sys/DEMON amd64 Thank you for all your time, and consideration. --Chris From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 21:50:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24F8F195 for ; Sun, 28 Sep 2014 21:50:51 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 01FCAC9C for ; Sun, 28 Sep 2014 21:50:50 +0000 (UTC) Received: from [172.16.0.55] (unknown [92.247.20.226]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 80E4854697 for ; Sun, 28 Sep 2014 21:50:49 +0000 (UTC) Message-ID: <542882B7.4060407@freebsd.org> Date: Sun, 28 Sep 2014 17:50:47 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Mesa-9: configure: error: C compiler cannot create executables References: <7b0a119ebc4d8d7813f92c0f94aba8d8.authenticated@ultimatedns.net> In-Reply-To: <7b0a119ebc4d8d7813f92c0f94aba8d8.authenticated@ultimatedns.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 21:50:51 -0000 On 09/28/2014 17:37, Chris H wrote: > Greetings, > A recent install of RELENG_9, followed by a build|install world|kernel. > Returns the following error when attempting an make install of > x11/xorg-minimal > > ===> Configuring for dri-9.1.7_5,2 > configure: loading site script /usr/ports/Templates/config.site > checking build system type... amd64-portbld-freebsd9.3 > checking host system type... amd64-portbld-freebsd9.3 > checking target system type... amd64-portbld-freebsd9.3 > checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p > checking for gawk... (cached) /usr/bin/awk > checking whether gmake sets $(MAKE)... yes > checking whether gmake supports nested variables... yes > checking for style of include used by gmake... GNU > checking for gcc... clang > checking whether the C compiler works... no > configure: error: in `/usr/ports/graphics/dri/work/Mesa-9.1.7': > configure: error: C compiler cannot create executables > See `config.log' for more details > ===> Script "configure" failed unexpectedly. > Please report the problem to x11@FreeBSD.org [maintainer] and attach the > "/usr/ports/graphics/dri/work/Mesa-9.1.7/config.log" including the output of > the failure of your make command. Also, it might be a good idea to provide > an overview of all packages installed on your system (e.g. a > /usr/local/sbin/pkg-static info -g -Ea). > *** [do-configure] Error code 1 > > Any thoughts on how to overcome this issue? > > Relevant info: > > # svn info /usr/src > > Path: /usr/src > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/stable/9 > Relative URL: ^/stable/9 > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 272203 > Node Kind: directory > Schedule: normal > Last Changed Author: thomas > Last Changed Rev: 272184 > Last Changed Date: 2014-09-26 12:13:13 -0700 (Fri, 26 Sep 2014) > > svn info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: svn://svn.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 369380 > Node Kind: directory > Schedule: normal > Last Changed Author: mva > Last Changed Rev: 369380 > Last Changed Date: 2014-09-27 01:34:11 -0700 (Sat, 27 Sep 2014) > > FreeBSD demon 9.3-STABLE FreeBSD 9.3-STABLE #0 r272203: Sat Sep 27 15:49:55 PDT 2014 > root@demon:/usr/obj/usr/src/sys/DEMON amd64 > > Thank you for all your time, and consideration. > > --Chris > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > What does config.log say? also 'clang -v' -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 22:11:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED23F61F; Sun, 28 Sep 2014 22:11:41 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 94576ED4; Sun, 28 Sep 2014 22:11:40 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8SMBsOT074065; Sun, 28 Sep 2014 15:12:00 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8SMBmmu074059; Sun, 28 Sep 2014 15:11:48 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sun, 28 Sep 2014 15:11:49 -0700 (PDT) Message-ID: <82259777bbe474bb5581c2b4a0b79f25.authenticated@ultimatedns.net> In-Reply-To: <542882B7.4060407@freebsd.org> References: <7b0a119ebc4d8d7813f92c0f94aba8d8.authenticated@ultimatedns.net> <542882B7.4060407@freebsd.org> Date: Sun, 28 Sep 2014 15:11:49 -0700 (PDT) Subject: Re: Mesa-9: configure: error: C compiler cannot create executables From: "Chris H" To: "Allan Jude" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20140928151148_51632" X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 22:11:42 -0000 ------=_20140928151148_51632 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > On 09/28/2014 17:37, Chris H wrote: >> Greetings, >> A recent install of RELENG_9, followed by a build|install world|kernel. >> Returns the following error when attempting an make install of >> x11/xorg-minimal >> >> ===> Configuring for dri-9.1.7_5,2 >> configure: loading site script /usr/ports/Templates/config.site >> checking build system type... amd64-portbld-freebsd9.3 >> checking host system type... amd64-portbld-freebsd9.3 >> checking target system type... amd64-portbld-freebsd9.3 >> checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel >> checking whether build environment is sane... yes >> checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p >> checking for gawk... (cached) /usr/bin/awk >> checking whether gmake sets $(MAKE)... yes >> checking whether gmake supports nested variables... yes >> checking for style of include used by gmake... GNU >> checking for gcc... clang >> checking whether the C compiler works... no >> configure: error: in `/usr/ports/graphics/dri/work/Mesa-9.1.7': >> configure: error: C compiler cannot create executables >> See `config.log' for more details >> ===> Script "configure" failed unexpectedly. >> Please report the problem to x11@FreeBSD.org [maintainer] and attach the >> "/usr/ports/graphics/dri/work/Mesa-9.1.7/config.log" including the output of >> the failure of your make command. Also, it might be a good idea to provide >> an overview of all packages installed on your system (e.g. a >> /usr/local/sbin/pkg-static info -g -Ea). >> *** [do-configure] Error code 1 >> >> Any thoughts on how to overcome this issue? >> >> Relevant info: >> >> # svn info /usr/src >> >> Path: /usr/src >> Working Copy Root Path: /usr/src >> URL: svn://svn.freebsd.org/base/stable/9 >> Relative URL: ^/stable/9 >> Repository Root: svn://svn.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 272203 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: thomas >> Last Changed Rev: 272184 >> Last Changed Date: 2014-09-26 12:13:13 -0700 (Fri, 26 Sep 2014) >> >> svn info /usr/ports >> Path: /usr/ports >> Working Copy Root Path: /usr/ports >> URL: svn://svn.freebsd.org/ports/head >> Relative URL: ^/head >> Repository Root: svn://svn.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 369380 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: mva >> Last Changed Rev: 369380 >> Last Changed Date: 2014-09-27 01:34:11 -0700 (Sat, 27 Sep 2014) >> >> FreeBSD demon 9.3-STABLE FreeBSD 9.3-STABLE #0 r272203: Sat Sep 27 15:49:55 PDT 2014 >> root@demon:/usr/obj/usr/src/sys/DEMON amd64 >> >> Thank you for all your time, and consideration. >> >> --Chris >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > What does config.log say? Please see attached (config.log.txt) -- it's big. :) > > also 'clang -v' nadda -- don't think it's installed -- WITHOUT_CLANG=true (/etc/make.conf) Thank you for your thoughtful reply, Allan. --Chris > > > -- > Allan Jude > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ------=_20140928151148_51632 Content-Type: text/plain; name="config.log.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="config.log.txt" This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Mesa configure 9.1.7, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --disable-gles2 --disable-egl --enable-gallium-llvm --disable-gallium-egl --with-gallium-drivers=r300,r600,radeonsi,svga,swrast --with-dri-drivers=i915 i965 r200 radeon swrast --x-libraries=/usr/local/lib --x-includes=/usr/local/include --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=amd64-portbld-freebsd9.3 ## --------- ## ## Platform. ## ## --------- ## hostname = demon uname -m = amd64 uname -r = 9.3-STABLE uname -s = FreeBSD uname -v = FreeBSD 9.3-STABLE #0 r272203: Sat Sep 27 15:49:55 PDT 2014 root@demon:/usr/obj/usr/src/sys/DEMON /usr/bin/uname -p = amd64 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /usr/bin PATH: /usr/games PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /root/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2778: loading site script /usr/ports/Templates/config.site | # $FreeBSD: head/Templates/config.site 349240 2014-03-26 11:16:42Z bapt $ | # Do not add: | # - toolchain related | # - arch-dependent values | # - anything "=no" unless guaranteed to never be | # implemented in FreeBSD | # - also avoid "working" values | # This file must reflect the oldest supported Release. | # | #MAINTAINER= portmgr@FreeBSD.org | | # Path | : ${ac_cv_path_BZIP2=/usr/bin/bzip2} | : ${ac_cv_path_EGREP=/usr/bin/egrep} | : ${ac_cv_path_FGREP=/usr/bin/fgrep} | : ${ac_cv_path_GREP=/usr/bin/grep} | : ${ac_cv_path_GZIP=/usr/bin/gzip} | : ${ac_cv_path_MKTEMP_COMMAND=/usr/bin/mktemp} | : ${ac_cv_path_SED=/usr/bin/sed} | : ${ac_cv_path_install=/usr/bin/install} | : ${ac_cv_path_mkdir=/bin/mkdir} | : ${ac_cv_prog_AWK=/usr/bin/awk} | : ${ac_cv_prog_SED=/usr/bin/sed} | : ${am_cv_prog_tar_ustar=/usr/bin/tar} | : ${cl_cv_prog_LN=/bin/ln} | : ${cl_cv_prog_cp='/bin/cp -p'} | : ${lt_cv_path_MAGIC_CMD=/usr/bin/file} | | # Headers | : ${ac_cv_header_alloca_h=no} | : ${ac_cv_header_arpa_inet_h=yes} | : ${ac_cv_header_arpa_nameser_h=yes} | : ${ac_cv_header_ctype_h=yes} | : ${ac_cv_header_dirent_h=yes} | : ${ac_cv_header_dlfcn_h=yes} | : ${ac_cv_header_elf_h=yes} | : ${ac_cv_header_errno_h=yes} | : ${ac_cv_header_fcntl_h=yes} | : ${ac_cv_header_float_h=yes} | : ${ac_cv_header_floatingpoint_h=yes} | : ${ac_cv_header_getopt_h=yes} | : ${ac_cv_header_glob_h=yes} | : ${ac_cv_header_inttypes_h=yes} | : ${ac_cv_header_langinfo_h=yes} | : ${ac_cv_header_libgen_h=yes} | : ${ac_cv_header_libutil_h=yes} | : ${ac_cv_header_limits_h=yes} | : ${ac_cv_header_login_cap_h=yes} | : ${ac_cv_header_math_h=yes} | : ${ac_cv_header_memory_h=yes} | : ${ac_cv_header_minix_config_h=no} | : ${ac_cv_header_net_if_h=yes} | : ${ac_cv_header_net_if_media_h=yes} | : ${ac_cv_header_net_if_tap_h=yes} | : ${ac_cv_header_net_if_tun_h=yes} | : ${ac_cv_header_netdb_h=yes} | : ${ac_cv_header_netinet_in_h=yes} | : ${ac_cv_header_paths_h=yes} | : ${ac_cv_header_poll_h=yes} | : ${ac_cv_header_pwd_h=yes} | : ${ac_cv_header_readpassphrase_h=yes} | : ${ac_cv_header_resolv_h=yes} | : ${ac_cv_header_rpc_types_h=yes} | : ${ac_cv_header_sched_h=yes} | : ${ac_cv_header_search_h=yes} | : ${ac_cv_header_security_pam_appl_h=yes} | : ${ac_cv_header_signal_h=yes} | : ${ac_cv_header_spawn_h=yes} | : ${ac_cv_header_stdarg_h=yes} | : ${ac_cv_header_stdbool_h=yes} | : ${ac_cv_header_stdc=yes} | : ${ac_cv_header_stddef_h=yes} | : ${ac_cv_header_stdint_h=yes} | : ${ac_cv_header_stdio_h=yes} | : ${ac_cv_header_stdlib_h=yes} | : ${ac_cv_header_string_h=yes} | : ${ac_cv_header_strings_h=yes} | : ${ac_cv_header_sys_acl_h=yes} | : ${ac_cv_header_sys_cdefs_h=yes} | : ${ac_cv_header_sys_dir_h=yes} | : ${ac_cv_header_sys_fcntl_h=yes} | : ${ac_cv_header_sys_file_h=yes} | : ${ac_cv_header_sys_ioctl_h=yes} | : ${ac_cv_header_sys_mman_h=yes} | : ${ac_cv_header_sys_mount_h=yes} | : ${ac_cv_header_sys_msg_h=yes} | : ${ac_cv_header_sys_param_h=yes} | : ${ac_cv_header_sys_poll_h=yes} | : ${ac_cv_header_sys_ptrace_h=yes} | : ${ac_cv_header_sys_select_h=yes} | : ${ac_cv_header_sys_socket_h=yes} | : ${ac_cv_header_sys_stat_h=yes} | : ${ac_cv_header_sys_statvfs_h=yes} | : ${ac_cv_header_sys_time_h=yes} | : ${ac_cv_header_sys_timers_h=yes} | : ${ac_cv_header_sys_times_h=yes} | : ${ac_cv_header_sys_types_h=yes} | : ${ac_cv_header_sys_un_h=yes} | : ${ac_cv_header_sys_wait_h=yes} | : ${ac_cv_header_time_h=yes} | : ${ac_cv_header_ttyent_h=yes} | : ${ac_cv_header_ucontext_h=yes} | : ${ac_cv_header_unistd_h=yes} | : ${ac_cv_header_utime_h=yes} | : ${ac_cv_header_vis_h=yes} | : ${ac_cv_header_wchar_h=yes} | : ${ac_cv_header_wctype_h=yes} | : ${ac_cv_header_zlib_h=yes} | | : ${gl_cv_header_wchar_h_correct_inline=yes} | | : ${ac_cv_header_argz_h=no} | : ${ac_cv_header_byteswap_h=no} | : ${ac_cv_header_dl_h=no} | : ${ac_cv_header_malloc_h=no} | : ${ac_cv_header_random_h=no} | : ${ac_cv_header_vfork_h=no} | | # This appears in FreeBSD 10 do not cache it. | #: ${gl_cv_have_raw_decl_strchrnul=yes} | : ${gl_cv_have_raw_decl_memcpy=no} | : ${gl_cv_have_raw_decl_memmem=yes} | : ${gl_cv_have_raw_decl_memrchr=yes} | : ${gl_cv_have_raw_decl_rawmemchr=yes} | : ${gl_cv_have_raw_decl_stpcpy=yes} | : ${gl_cv_have_raw_decl_stpncpy=yes} | : ${gl_cv_have_raw_decl_strcasestr=yes} | : ${gl_cv_have_raw_decl_strdup=yes} | : ${gl_cv_have_raw_decl_strncat=yes} | : ${gl_cv_have_raw_decl_strndup=yes} | : ${gl_cv_have_raw_decl_strnlen=yes} | : ${gl_cv_have_raw_decl_strpbrk=yes} | : ${gl_cv_have_raw_decl_strsep=yes} | : ${gl_cv_have_raw_decl_strsignal=yes} | : ${gl_cv_have_raw_decl_strtok_r=yes} | : ${gl_cv_have_raw_decl_strverscmp=no} | | # Type | : ${ac_cv_c_int16_t=yes} | : ${ac_cv_c_int32_t=yes} | : ${ac_cv_c_int64_t=yes} | : ${ac_cv_c_int8_t=yes} | : ${ac_cv_c_uint16_t=yes} | : ${ac_cv_c_uint32_t=yes} | : ${ac_cv_c_uint64_t=yes} | : ${ac_cv_c_uint8_t=yes} | | : ${ac_cv_type__Bool=yes} | : ${ac_cv_type_char=yes} | : ${ac_cv_type_char_p=yes} | : ${ac_cv_type_fsblkcnt_t=yes} | : ${ac_cv_type_fsfilcnt_t=yes} | : ${ac_cv_type_in_addr_t=yes} | : ${ac_cv_type_in_port_t=yes} | : ${ac_cv_type_int16_t=yes} | : ${ac_cv_type_int32_t=yes} | : ${ac_cv_type_int=yes} | : ${ac_cv_type_intmax_t=yes} | : ${ac_cv_type_long=yes} | : ${ac_cv_type_long_double=yes} | : ${ac_cv_type_long_long=yes} | : ${ac_cv_type_long_long_int=yes} | : ${ac_cv_type_mbstate_t=yes} | : ${ac_cv_type_mode_t=yes} | : ${ac_cv_type_nlink_t=yes} | : ${ac_cv_type_off_t=yes} | : ${ac_cv_type_pid_t=yes} | : ${ac_cv_type_posix_spawn_file_actions_t=yes} | : ${ac_cv_type_posix_spawnattr_t=yes} | : ${ac_cv_type_ptrdiff_t=yes} | : ${ac_cv_type_short=yes} | : ${ac_cv_type_sig_atomic_t=yes} | : ${ac_cv_type_sigset_t=yes} | : ${ac_cv_type_size_t=yes} | : ${ac_cv_type_socklen_t=yes} | : ${ac_cv_type_ssize_t=yes} | : ${ac_cv_type_stack_t=yes} | : ${ac_cv_type_struct_timespec=yes} | : ${ac_cv_type_u_char=yes} | : ${ac_cv_type_u_int16_t=yes} | : ${ac_cv_type_u_int32_t=yes} | : ${ac_cv_type_u_int8_t=yes} | : ${ac_cv_type_u_int=yes} | : ${ac_cv_type_u_long=yes} | : ${ac_cv_type_u_short=yes} | : ${ac_cv_type_uid_t=yes} | : ${ac_cv_type_uintptr_t=yes} | : ${ac_cv_type_unsigned_char=yes} | : ${ac_cv_type_unsigned_int=yes} | : ${ac_cv_type_unsigned_long=yes} | : ${ac_cv_type_unsigned_long_long=yes} | : ${ac_cv_type_unsigned_long_long_int=yes} | : ${ac_cv_type_unsigned_short=yes} | : ${ac_cv_type_volatile_sig_atomic_t=yes} | : ${ac_cv_type_wchar_t=yes} | : ${ac_cv_type_wint_t=yes} | | : ${gl_cv_sigaltstack_low_base=yes} | : ${gl_cv_size_max=yes} | : ${gl_cv_type_sigset_t=yes} | : ${gl_cv_type_wchar_t_signed=yes} | : ${gl_cv_type_wctrans_t=yes} | : ${gl_cv_type_wctype_t=yes} | : ${gl_cv_type_wint_t_signed=yes} | : ${gl_cv_var_stdin_large_offset=yes} | : ${gt_cv_c_intmax_t=yes} | : ${gt_cv_c_wchar_t=yes} | : ${gt_cv_c_wint_t=yes} | : ${gt_cv_func_printf_posix=yes} | : ${gt_cv_int_divbyzero_sigfpe=yes} | : ${gt_cv_siginfo_t=yes} | : ${gt_cv_ssize_t=yes} | | # lib | : ${ac_cv_lib_crypt_crypt=yes} | : ${ac_cv_lib_edit_el_init=yes} | : ${ac_cv_lib_pam_pam_set_item=yes} | : ${ac_cv_lib_z_deflate=yes} | : ${ac_cv_libc_defines___progname=yes} | : ${ac_cv_libc_defines_sys_errlist=yes} | : ${ac_cv_libc_defines_sys_nerr=yes} | | # Struct | : ${ac_cv_member_HEADER_ad=yes} | : ${ac_cv_member_struct___res_state_retrans=yes} | : ${ac_cv_member_struct_sigaction_sa_sigaction=yes} | : ${ac_cv_member_struct_sockaddr_in6_sin6_scope_id=yes} | : ${ac_cv_member_struct_stat_st_blksize=yes} | | : ${gl_cv_sys_struct_timespec_in_time_h=yes} | : ${gl_cv_sys_struct_timeval=yes} | | # Has appearred in FreeBSD 10 | #: ${ac_cv_func_waitid=yes} | # Has appearred in FreeBSD 10 | #: ${ac_cv_func_strchrnul=yes} | # Has appearred in FreeBSD 9 | #: ${ac_cv_func_uselocale=yes} | #: ${ac_cv_func_newlocale=yes} | | # Functions | : ${ac_cv_func___b64_ntop=yes} | : ${ac_cv_func___b64_pton=yes} | : ${ac_cv_func__getlong=yes} | : ${ac_cv_func__getshort=yes} | : ${ac_cv_func__getshort=yes} | : ${ac_cv_func__stat=yes} | : ${ac_cv_func_acl_create_entry_np=yes} | : ${ac_cv_func_acl_delete_def_file=yes} | : ${ac_cv_func_acl_delete_fd_np=yes} | : ${ac_cv_func_acl_delete_file_np=yes} | : ${ac_cv_func_acl_free=yes} | : ${ac_cv_func_acl_from_text=yes} | : ${ac_cv_func_acl_get_fd=yes} | : ${ac_cv_func_acl_get_file=yes} | : ${ac_cv_func_acl_set_fd=yes} | : ${ac_cv_func_acl_set_file=yes} | : ${ac_cv_func_alarm=yes} | : ${ac_cv_func_alloca=yes} | : ${ac_cv_func_arc4random=yes} | : ${ac_cv_func_arc4random_buf=yes} | : ${ac_cv_func_arc4random_uniform=yes} | : ${ac_cv_func_asprintf=yes} | : ${ac_cv_func_atexit=yes} | : ${ac_cv_func_bcmp=yes} | : ${ac_cv_func_bcopy=yes} | : ${ac_cv_func_bindresvport_sa=yes} | : ${ac_cv_func_btowc=yes} | : ${ac_cv_func_bzero=yes} | : ${ac_cv_func_chown=yes} | : ${ac_cv_func_clock=yes} | : ${ac_cv_func_clock_gettime=yes} | : ${ac_cv_func_closedir=yes} | : ${ac_cv_func_closefrom=yes} | : ${ac_cv_func_daemon=yes} | : ${ac_cv_func_dirname=yes} | : ${ac_cv_func_dlopen=yes} | : ${ac_cv_func_dup2=yes} | : ${ac_cv_func_eaccess=yes} | : ${ac_cv_func_fchmod=yes} | : ${ac_cv_func_fchown=yes} | : ${ac_cv_func_fcntl=yes} | : ${ac_cv_func_fileno=yes} | : ${ac_cv_func_fork=yes} | : ${ac_cv_func_fpurge=yes} | : ${ac_cv_func_freeaddrinfo=yes} | : ${ac_cv_func_fstatvfs=yes} | : ${ac_cv_func_fsync=yes} | : ${ac_cv_func_futimes=yes} | : ${ac_cv_func_fwprintf=yes} | : ${ac_cv_func_gai_strerror=yes} | : ${ac_cv_func_getaddrinfo=yes} | : ${ac_cv_func_getcwd=yes} | : ${ac_cv_func_getdelim=yes} | : ${ac_cv_func_getdtablesize=yes} | : ${ac_cv_func_getegid=yes} | : ${ac_cv_func_geteuid=yes} | : ${ac_cv_func_getgid=yes} | : ${ac_cv_func_getgrouplist=yes} | : ${ac_cv_func_gethostbyname=yes} | : ${ac_cv_func_gethostname=yes} | : ${ac_cv_func_getline=yes} | : ${ac_cv_func_getnameinfo=yes} | : ${ac_cv_func_getopt=yes} | : ${ac_cv_func_getopt_long_only=yes} | : ${ac_cv_func_getpagesize=yes} | : ${ac_cv_func_getpeereid=yes} | : ${ac_cv_func_getpgid=yes} | : ${ac_cv_func_getpgrp=yes} | : ${ac_cv_func_getpgrp_void=yes} | : ${ac_cv_func_getpid=yes} | : ${ac_cv_func_getrlimit=yes} | : ${ac_cv_func_getrusage=yes} | : ${ac_cv_func_gettimeofday=yes} | : ${ac_cv_func_getttyent=yes} | : ${ac_cv_func_getuid=yes} | : ${ac_cv_func_getwd=yes} | : ${ac_cv_func_glob=yes} | : ${ac_cv_func_group_from_gid=yes} | : ${ac_cv_func_inet_aton=yes} | : ${ac_cv_func_inet_ntoa=yes} | : ${ac_cv_func_inet_ntop=yes} | : ${ac_cv_func_innetgr=yes} | : ${ac_cv_func_isascii=yes} | : ${ac_cv_func_isascii=yes} | : ${ac_cv_func_isblank=yes} | : ${ac_cv_func_issetugid=yes} | : ${ac_cv_func_iswblank=yes} | : ${ac_cv_func_iswcntrl=yes} | : ${ac_cv_func_iswctype=yes} | : ${ac_cv_func_link=yes} | : ${ac_cv_func_localtime=yes} | : ${ac_cv_func_login_getcapbool=yes} | : ${ac_cv_func_lstat=yes} | : ${ac_cv_func_lstat_dereferences_slashed_symlink=yes} | : ${ac_cv_func_malloc_0_nonnull=yes} | : ${ac_cv_func_mbrlen=yes} | : ${ac_cv_func_mbrtowc=yes} | : ${ac_cv_func_mbsinit=yes} | : ${ac_cv_func_mbsrtowcs=yes} | : ${ac_cv_func_memchr=yes} | : ${ac_cv_func_memcmp=yes} | : ${ac_cv_func_memcpy=yes} | : ${ac_cv_func_memmove=yes} | : ${ac_cv_func_memset=yes} | : ${ac_cv_func_mkdtemp=yes} | : ${ac_cv_func_mkstemp=yes} | : ${ac_cv_func_mktemp=yes} | : ${ac_cv_func_mlock=yes} | : ${ac_cv_func_mmap=yes} | : ${ac_cv_func_mmap_fixed_mapped=yes} | : ${ac_cv_func_mprotect=yes} | : ${ac_cv_func_munlock=yes} | : ${ac_cv_func_munmap=yes} | : ${ac_cv_func_nl_langinfo=yes} | : ${ac_cv_func_opendir=yes} | # Breaks heimdal and rancid at least | # : ${ac_cv_func_openpty=yes} | : ${ac_cv_func_pam_getenvlist=yes} | : ${ac_cv_func_pam_putenv=yes} | : ${ac_cv_func_pathconf=yes} | : ${ac_cv_func_pipe=yes} | : ${ac_cv_func_poll=yes} | : ${ac_cv_func_posix_spawn=yes} | : ${ac_cv_func_pread=yes} | : ${ac_cv_func_pthread_cond_broadcast=yes} | : ${ac_cv_func_pthread_cond_destroy=yes} | : ${ac_cv_func_pthread_cond_init=yes} | : ${ac_cv_func_pthread_cond_signal=yes} | : ${ac_cv_func_pthread_cond_timedwait=yes} | : ${ac_cv_func_pthread_cond_wait=yes} | : ${ac_cv_func_pthread_equal=yes} | : ${ac_cv_func_pthread_exit=yes} | : ${ac_cv_func_pthread_mutex_destroy=yes} | : ${ac_cv_func_pthread_mutex_init=yes} | : ${ac_cv_func_pthread_mutex_lock=yes} | : ${ac_cv_func_pthread_mutex_unlock=yes} | : ${ac_cv_func_pthread_self=yes} | : ${ac_cv_func_putenv=yes} | : ${ac_cv_func_pwrite=yes} | : ${ac_cv_func_raise=yes} | : ${ac_cv_func_rand=yes} | : ${ac_cv_func_random=yes} | : ${ac_cv_func_readdir=yes} | : ${ac_cv_func_readlink=yes} | : ${ac_cv_func_readlinkat=yes} | : ${ac_cv_func_readpassphrase=yes} | : ${ac_cv_func_realpath=yes} | : ${ac_cv_func_recvmsg=yes} | : ${ac_cv_func_rename=yes} | : ${ac_cv_func_rresvport_af=yes} | : ${ac_cv_func_sched_yield=yes} | : ${ac_cv_func_select=yes} | : ${ac_cv_func_sendmsg=yes} | : ${ac_cv_func_setegid=yes} | : ${ac_cv_func_setenv=yes} | : ${ac_cv_func_seteuid=yes} | : ${ac_cv_func_setgroupent=yes} | : ${ac_cv_func_setgroups=yes} | : ${ac_cv_func_setlinebuf=yes} | : ${ac_cv_func_setlocale=yes} | : ${ac_cv_func_setlogin=yes} | : ${ac_cv_func_setpassent=yes} | : ${ac_cv_func_setproctitle=yes} | : ${ac_cv_func_setregid=yes} | : ${ac_cv_func_setresgid=yes} | : ${ac_cv_func_setresuid=yes} | : ${ac_cv_func_setreuid=yes} | : ${ac_cv_func_setrlimit=yes} | : ${ac_cv_func_setsid=yes} | : ${ac_cv_func_setsockopt=yes} | : ${ac_cv_func_setvbuf=yes} | : ${ac_cv_func_shmget=yes} | : ${ac_cv_func_sigaction=yes} | : ${ac_cv_func_sigaltstack=yes} | : ${ac_cv_func_siginterrupt=yes} | : ${ac_cv_func_sigprocmask=yes} | : ${ac_cv_func_sigvec=yes} | : ${ac_cv_func_sleep=yes} | : ${ac_cv_func_snprintf=yes} | : ${ac_cv_func_socketpair=yes} | : ${ac_cv_func_srand=yes} | : ${ac_cv_func_srandom=yes} | : ${ac_cv_func_stat=yes} | : ${ac_cv_func_statfs=yes} | : ${ac_cv_func_statvfs=yes} | : ${ac_cv_func_stpcpy=yes} | : ${ac_cv_func_stpncpy=yes} | : ${ac_cv_func_strbrk=yes} | : ${ac_cv_func_strcasecmp=yes} | : ${ac_cv_func_strcspn=yes} | : ${ac_cv_func_strdup=yes} | : ${ac_cv_func_strerror=yes} | : ${ac_cv_func_strerror_r=yes} | : ${ac_cv_func_strftime=yes} | : ${ac_cv_func_strlcat=yes} | : ${ac_cv_func_strlcpy=yes} | : ${ac_cv_func_strlen=yes} | : ${ac_cv_func_strmode=yes} | : ${ac_cv_func_strncasecmp=yes} | : ${ac_cv_func_strndup=yes} | : ${ac_cv_func_strnlen=yes} | : ${ac_cv_func_strnlen_working=yes} | : ${ac_cv_func_strpbrk=yes} | : ${ac_cv_func_strptime=yes} | : ${ac_cv_func_strsep=yes} | : ${ac_cv_func_strsignal=yes} | : ${ac_cv_func_strtol=yes} | : ${ac_cv_func_strtoll=yes} | : ${ac_cv_func_strtonum=yes} | : ${ac_cv_func_strtoul=yes} | : ${ac_cv_func_strtoull=yes} | : ${ac_cv_func_symlink=yes} | : ${ac_cv_func_sysconf=yes} | : ${ac_cv_func_tcgetpgrp=yes} | : ${ac_cv_func_time=yes} | : ${ac_cv_func_towlower=yes} | : ${ac_cv_func_truncate=yes} | : ${ac_cv_func_tsearch=yes} | : ${ac_cv_func_uname=yes} | : ${ac_cv_func_unsetenv=yes} | : ${ac_cv_func_user_from_uid=yes} | : ${ac_cv_func_usleep=yes} | : ${ac_cv_func_utime=yes} | : ${ac_cv_func_utimes=yes} | : ${ac_cv_func_vasprintf=yes} | : ${ac_cv_func_vfork=yes} | : ${ac_cv_func_vprintf=yes} | : ${ac_cv_func_vsnprintf=yes} | : ${ac_cv_func_vsprintf=yes} | : ${ac_cv_func_waitpid=yes} | : ${ac_cv_func_wcrtomb=yes} | : ${ac_cv_func_wcscoll=yes} | : ${ac_cv_func_wcslen=yes} | : ${ac_cv_func_wcsnlen=yes} | : ${ac_cv_func_wctob=yes} | : ${ac_cv_func_wcwidth=yes} | : ${ac_cv_func_wmemchr=yes} | : ${ac_cv_func_wmemcpy=yes} | : ${ac_cv_func_yp_match=yes} | | # non existing functions | : ${ac_cv_func_argz_count=no} | : ${ac_cv_func_argz_next=no} | : ${ac_cv_func_argz_stringify=no} | : ${ac_cv_func_obstacks=no} | : ${ac_cv_func_pstat_getdynamic=no} | : ${ac_cv_func_rawmemchr=no} | : ${ac_cv_func_yield=no} | | : ${ac_cv_have___va_copy=yes} | : ${ac_cv_have_clock_t=yes} | : ${ac_cv_have_control_in_msghdr=yes} | : ${ac_cv_have_getopt_optreset=yes} | : ${ac_cv_have_int64_t=yes} | : ${ac_cv_have_intxx_t=yes} | : ${ac_cv_have_mode_t=yes} | : ${ac_cv_have_pid_t=yes} | : ${ac_cv_have_pw_change_in_struct_passwd=yes} | : ${ac_cv_have_pw_class_in_struct_passwd=yes} | : ${ac_cv_have_pw_expire_in_struct_passwd=yes} | : ${ac_cv_have_sa_family_t=yes} | : ${ac_cv_have_size_t=yes} | : ${ac_cv_have_ss_family_in_struct_ss=yes} | : ${ac_cv_have_ssize_t=yes} | : ${ac_cv_have_struct_addrinfo=yes} | : ${ac_cv_have_struct_in6_addr=yes} | : ${ac_cv_have_struct_sockaddr_in6=yes} | : ${ac_cv_have_struct_sockaddr_storage=yes} | : ${ac_cv_have_struct_timeval=yes} | : ${ac_cv_have_u_char=yes} | : ${ac_cv_have_u_int64_t=yes} | : ${ac_cv_have_u_int=yes} | : ${ac_cv_have_u_intxx_t=yes} | : ${ac_cv_have_va_copy=yes} | | : ${ac_cv_have_decl_GLOB_NOMATCH=yes} | : ${ac_cv_have_decl_LLONG_MAX=yes} | : ${ac_cv_have_decl_MAXSYMLINKS=yes} | : ${ac_cv_have_decl_O_NONBLOCK=yes} | : ${ac_cv_have_decl_RLIMIT_NPROC=yes} | : ${ac_cv_have_decl_SHUT_RD=yes} | : ${ac_cv_have_decl__Exit=yes} | : ${ac_cv_have_decl_alarm=yes} | : ${ac_cv_have_decl_alphasort=yes} | : ${ac_cv_have_decl_atoll=yes} | : ${ac_cv_have_decl_btowc=yes} | : ${ac_cv_have_decl_chdir=yes} | : ${ac_cv_have_decl_chown=yes} | : ${ac_cv_have_decl_clearerr_unlocked=yes} | : ${ac_cv_have_decl_closedir=yes} | : ${ac_cv_have_decl_dprintf=yes} | : ${ac_cv_have_decl_dup2=yes} | : ${ac_cv_have_decl_dup=yes} | : ${ac_cv_have_decl_endusershell=yes} | : ${ac_cv_have_decl_faccessat=yes} | : ${ac_cv_have_decl_fchdir=yes} | : ${ac_cv_have_decl_fchmodat=yes} | : ${ac_cv_have_decl_fchownat=yes} | : ${ac_cv_have_decl_fcntl=yes} | : ${ac_cv_have_decl_fdopendir=yes} | : ${ac_cv_have_decl_feof_unlocked=yes} | : ${ac_cv_have_decl_feof_unlocked_fgets_unlocked=yes} | : ${ac_cv_have_decl_ferror_unlocked=yes} | : ${ac_cv_have_decl_ffsl=yes} | : ${ac_cv_have_decl_ffsll=yes} | : ${ac_cv_have_decl_fpurge=yes} | : ${ac_cv_have_decl_frexpl=yes} | : ${ac_cv_have_decl_fseeko=yes} | : ${ac_cv_have_decl_fstat=yes} | : ${ac_cv_have_decl_fstatat=yes} | : ${ac_cv_have_decl_fsync=yes} | : ${ac_cv_have_decl_ftello=yes} | : ${ac_cv_have_decl_ftruncate=yes} | : ${ac_cv_have_decl_getc_unlocked=yes} | : ${ac_cv_have_decl_getchar_unlocked=yes} | : ${ac_cv_have_decl_getcwd=yes} | : ${ac_cv_have_decl_getdelim=yes} | : ${ac_cv_have_decl_getdomainname=yes} | : ${ac_cv_have_decl_getdtablesize=yes} | : ${ac_cv_have_decl_getenv=yes} | : ${ac_cv_have_decl_getgroups=yes} | : ${ac_cv_have_decl_gethostname=yes} | : ${ac_cv_have_decl_getline=yes} | : ${ac_cv_have_decl_getloadavg=yes} | : ${ac_cv_have_decl_getlogin=yes} | : ${ac_cv_have_decl_getlogin_r=yes} | : ${ac_cv_have_decl_getpagesize=yes} | : ${ac_cv_have_decl_gets=yes} | : ${ac_cv_have_decl_getsubopt=yes} | : ${ac_cv_have_decl_gettimeofday=yes} | : ${ac_cv_have_decl_getusershell=yes} | : ${ac_cv_have_decl_grantpt=yes} | : ${ac_cv_have_decl_h_errno=yes} | : ${ac_cv_have_decl_imaxabs=yes} | : ${ac_cv_have_decl_imaxdiv=yes} | : ${ac_cv_have_decl_initstate=yes} | : ${ac_cv_have_decl_isatty=yes} | : ${ac_cv_have_decl_isblank=yes} | : ${ac_cv_have_decl_iswblank=yes} | : ${ac_cv_have_decl_iswctype=yes} | : ${ac_cv_have_decl_lchmod=yes} | : ${ac_cv_have_decl_lchown=yes} | : ${ac_cv_have_decl_link=yes} | : ${ac_cv_have_decl_linkat=yes} | : ${ac_cv_have_decl_lseek=yes} | : ${ac_cv_have_decl_lstat=yes} | : ${ac_cv_have_decl_mbrlen=yes} | : ${ac_cv_have_decl_mbrtowc=yes} | : ${ac_cv_have_decl_mbsinit=yes} | : ${ac_cv_have_decl_mbsnrtowcs=yes} | : ${ac_cv_have_decl_mbsrtowcs=yes} | : ${ac_cv_have_decl_memmem=yes} | : ${ac_cv_have_decl_memrchr=yes} | : ${ac_cv_have_decl_mkdirat=yes} | : ${ac_cv_have_decl_mkdtemp=yes} | : ${ac_cv_have_decl_mkfifo=yes} | : ${ac_cv_have_decl_mkfifoat=yes} | : ${ac_cv_have_decl_mknod=yes} | : ${ac_cv_have_decl_mknodat=yes} | : ${ac_cv_have_decl_mkstemp=yes} | : ${ac_cv_have_decl_nl_langinfo=yes} | : ${ac_cv_have_decl_offsetof=yes} | : ${ac_cv_have_decl_openat=yes} | : ${ac_cv_have_decl_opendir=yes} | : ${ac_cv_have_decl_pclose=yes} | : ${ac_cv_have_decl_pipe=yes} | : ${ac_cv_have_decl_popen=yes} | : ${ac_cv_have_decl_posix_openpt=yes} | : ${ac_cv_have_decl_posix_spawn=yes} | : ${ac_cv_have_decl_posix_spawn_file_actions_addclose=yes} | : ${ac_cv_have_decl_posix_spawn_file_actions_adddup2=yes} | : ${ac_cv_have_decl_posix_spawn_file_actions_addopen=yes} | : ${ac_cv_have_decl_posix_spawn_file_actions_destroy=yes} | : ${ac_cv_have_decl_posix_spawn_file_actions_init=yes} | : ${ac_cv_have_decl_posix_spawnattr_destroy=yes} | : ${ac_cv_have_decl_posix_spawnattr_getflags=yes} | : ${ac_cv_have_decl_posix_spawnattr_getpgroup=yes} | : ${ac_cv_have_decl_posix_spawnattr_getschedparam=yes} | : ${ac_cv_have_decl_posix_spawnattr_getschedpolicy=yes} | : ${ac_cv_have_decl_posix_spawnattr_getsigdefault=yes} | : ${ac_cv_have_decl_posix_spawnattr_getsigmask=yes} | : ${ac_cv_have_decl_posix_spawnattr_init=yes} | : ${ac_cv_have_decl_posix_spawnattr_setflags=yes} | : ${ac_cv_have_decl_posix_spawnattr_setpgroup=yes} | : ${ac_cv_have_decl_posix_spawnattr_setschedparam=yes} | : ${ac_cv_have_decl_posix_spawnattr_setschedpolicy=yes} | : ${ac_cv_have_decl_posix_spawnattr_setsigdefault=yes} | : ${ac_cv_have_decl_posix_spawnattr_setsigmask=yes} | : ${ac_cv_have_decl_posix_spawnp=yes} | : ${ac_cv_have_decl_pread=yes} | : ${ac_cv_have_decl_pselect=yes} | : ${ac_cv_have_decl_pthread_sigmask=yes} | : ${ac_cv_have_decl_ptsname=yes} | : ${ac_cv_have_decl_putc_unlocked=yes} | : ${ac_cv_have_decl_putchar_unlocked=yes} | : ${ac_cv_have_decl_pwrite=yes} | : ${ac_cv_have_decl_random=yes} | : ${ac_cv_have_decl_rawmemchr=yes} | : ${ac_cv_have_decl_readdir=yes} | : ${ac_cv_have_decl_readlink=yes} | : ${ac_cv_have_decl_readlinkat=yes} | : ${ac_cv_have_decl_realpath=yes} | : ${ac_cv_have_decl_renameat=yes} | : ${ac_cv_have_decl_rewinddir=yes} | : ${ac_cv_have_decl_rmdir=yes} | : ${ac_cv_have_decl_rpmatch=yes} | : ${ac_cv_have_decl_scandir=yes} | : ${ac_cv_have_decl_select=yes} | : ${ac_cv_have_decl_setenv=yes} | : ${ac_cv_have_decl_sethostname=yes} | : ${ac_cv_have_decl_setlocale=yes} | : ${ac_cv_have_decl_setstate=yes} | : ${ac_cv_have_decl_setusershell=yes} | : ${ac_cv_have_decl_sigaction=yes} | : ${ac_cv_have_decl_sigaddset=yes} | : ${ac_cv_have_decl_sigaltstack=yes} | : ${ac_cv_have_decl_sigdelset=yes} | : ${ac_cv_have_decl_sigemptyset=yes} | : ${ac_cv_have_decl_sigfillset=yes} | : ${ac_cv_have_decl_sigismember=yes} | : ${ac_cv_have_decl_sigpending=yes} | : ${ac_cv_have_decl_sigprocmask=yes} | : ${ac_cv_have_decl_sleep=yes} | : ${ac_cv_have_decl_snprintf=yes} | : ${ac_cv_have_decl_srandom=yes} | : ${ac_cv_have_decl_stat=yes} | : ${ac_cv_have_decl_stpcpy=yes} | : ${ac_cv_have_decl_stpncpy=yes} | : ${ac_cv_have_decl_strcasestr=yes} | : ${ac_cv_have_decl_strdup=yes} | : ${ac_cv_have_decl_strerror_r=yes} | : ${ac_cv_have_decl_strncat=yes} | : ${ac_cv_have_decl_strndup=yes} | : ${ac_cv_have_decl_strnlen=yes} | : ${ac_cv_have_decl_strpbrk=yes} | : ${ac_cv_have_decl_strsep=yes} | : ${ac_cv_have_decl_strsignal=yes} | : ${ac_cv_have_decl_strtod=yes} | : ${ac_cv_have_decl_strtoimax=yes} | : ${ac_cv_have_decl_strtok_r=yes} | : ${ac_cv_have_decl_strtoll=yes} | : ${ac_cv_have_decl_strtoull=yes} | : ${ac_cv_have_decl_strtoumax=yes} | : ${ac_cv_have_decl_symlink=yes} | : ${ac_cv_have_decl_symlinkat=yes} | : ${ac_cv_have_decl_sys_siglist=yes} | : ${ac_cv_have_decl_tcsendbreak=yes} | : ${ac_cv_have_decl_tmpfile=yes} | : ${ac_cv_have_decl_towctrans=yes} | : ${ac_cv_have_decl_ttyname_r=yes} | : ${ac_cv_have_decl_unlink=yes} | : ${ac_cv_have_decl_unlinkat=yes} | : ${ac_cv_have_decl_unlockpt=yes} | : ${ac_cv_have_decl_unsetenv=yes} | : ${ac_cv_have_decl_usleep=yes} | : ${ac_cv_have_decl_vdprintf=yes} | : ${ac_cv_have_decl_vsnprintf=yes} | : ${ac_cv_have_decl_waitpid=yes} | : ${ac_cv_have_decl_wcpcpy=yes} | : ${ac_cv_have_decl_wcpncpy=yes} | : ${ac_cv_have_decl_wcrtomb=yes} | : ${ac_cv_have_decl_wcscasecmp=yes} | : ${ac_cv_have_decl_wcscat=yes} | : ${ac_cv_have_decl_wcschr=yes} | : ${ac_cv_have_decl_wcscmp=yes} | : ${ac_cv_have_decl_wcscoll=yes} | : ${ac_cv_have_decl_wcscpy=yes} | : ${ac_cv_have_decl_wcscspn=yes} | : ${ac_cv_have_decl_wcsdup=yes} | : ${ac_cv_have_decl_wcslen=yes} | : ${ac_cv_have_decl_wcsncasecmp=yes} | : ${ac_cv_have_decl_wcsncat=yes} | : ${ac_cv_have_decl_wcsncmp=yes} | : ${ac_cv_have_decl_wcsncpy=yes} | : ${ac_cv_have_decl_wcsnlen=yes} | : ${ac_cv_have_decl_wcsnrtombs=yes} | : ${ac_cv_have_decl_wcspbrk=yes} | : ${ac_cv_have_decl_wcsrchr=yes} | : ${ac_cv_have_decl_wcsrtombs=yes} | : ${ac_cv_have_decl_wcsspn=yes} | : ${ac_cv_have_decl_wcsstr=yes} | : ${ac_cv_have_decl_wcstok=yes} | : ${ac_cv_have_decl_wcswidth=yes} | : ${ac_cv_have_decl_wcsxfrm=yes} | : ${ac_cv_have_decl_wctob=yes} | : ${ac_cv_have_decl_wctrans=yes} | : ${ac_cv_have_decl_wctype=yes} | : ${ac_cv_have_decl_wcwidth=yes} | : ${ac_cv_have_decl_wmemchr=yes} | : ${ac_cv_have_decl_wmemcmp=yes} | : ${ac_cv_have_decl_wmemcpy=yes} | : ${ac_cv_have_decl_wmemmove=yes} | : ${ac_cv_have_decl_wmemset=yes} | : ${ac_cv_have_decl_writev=yes} | | # function specific | | : ${gl_cv_func_btowc_eof=yes} | : ${gl_cv_func_btowc_nul=yes} | : ${gl_cv_func_fcntl_f_dupfd_cloexec=yes} | : ${gl_cv_func_fnmatch_posix=yes} | : ${gl_cv_func_fopen_slash=yes} | : ${gl_cv_func_frexp_no_libm=yes} | : ${gl_cv_func_fseeko=yes} | : ${gl_cv_func_ftello=yes} | : ${gl_cv_func_getcwd_null=yes} | : ${gl_cv_func_getcwd_posix_signature=yes} | : ${gl_cv_func_getopt_posix=yes} | : ${gl_cv_func_isnand_no_libm=yes} | : ${gl_cv_func_ldexp_no_libm=yes} | : ${gl_cv_func_lseek_pipe=yes} | : ${gl_cv_func_lstat_dereferences_slashed_symlink=yes} | : ${gl_cv_func_malloc_0_nonnull=1} | : ${gl_cv_func_malloc_posix=yes} | : ${gl_cv_func_mbrtowc_incomplete_state=yes} | : ${gl_cv_func_mbrtowc_nul_retval=yes} | : ${gl_cv_func_mbrtowc_null_arg1=yes} | : ${gl_cv_func_mbrtowc_null_arg2=yes} | : ${gl_cv_func_mbrtowc_retval=yes} | : ${gl_cv_func_mbrtowc_sanitycheck=yes} | : ${gl_cv_func_open_slash=yes} | : ${gl_cv_func_printf_directive_a=yes} | : ${gl_cv_func_printf_directive_f=yes} | : ${gl_cv_func_printf_directive_ls=yes} | : ${gl_cv_func_printf_directive_n=yes} | : ${gl_cv_func_printf_flag_grouping=yes} | : ${gl_cv_func_printf_flag_leftadjust=yes} | : ${gl_cv_func_printf_flag_zero=yes} | : ${gl_cv_func_printf_infinite=yes} | : ${gl_cv_func_printf_long_double=yes} | : ${gl_cv_func_printf_positions=yes} | : ${gl_cv_func_printf_precision=yes} | : ${gl_cv_func_printf_sizes_c99=yes} | : ${gl_cv_func_sigprocmask=1} | : ${gl_cv_func_snprintf_retval_c99=yes} | : ${gl_cv_func_snprintf_size1=yes} | : ${gl_cv_func_snprintf_usable=yes} | : ${gl_cv_func_spawnattr_setschedparam=yes} | : ${gl_cv_func_spawnattr_setschedpolicy=yes} | : ${gl_cv_func_stat_dir_slash=yes} | : ${gl_cv_func_stat_file_slash=yes} | : ${gl_cv_func_stpncpy=yes} | : ${gl_cv_func_va_copy=yes} | : ${gl_cv_func_wcrtomb_retval=yes} | : ${gt_cv_func_unsetenv_ret=int} | | : ${gl_cv_have_include_next=yes} | | : ${gl_cv_have_raw_decl_rawmemchr=yes} | : ${gl_cv_have_raw_decl__Exit=yes} | : ${gl_cv_have_raw_decl_alphasort=yes} | : ${gl_cv_have_raw_decl_atoll=yes} | : ${gl_cv_have_raw_decl_btowc=yes} | : ${gl_cv_have_raw_decl_chdir=yes} | : ${gl_cv_have_raw_decl_chown=yes} | : ${gl_cv_have_raw_decl_closedir=yes} | : ${gl_cv_have_raw_decl_dprintf=yes} | : ${gl_cv_have_raw_decl_dup2=yes} | : ${gl_cv_have_raw_decl_dup=yes} | : ${gl_cv_have_raw_decl_endusershell=yes} | : ${gl_cv_have_raw_decl_faccessat=yes} | : ${gl_cv_have_raw_decl_fchdir=yes} | : ${gl_cv_have_raw_decl_fchmodat=yes} | : ${gl_cv_have_raw_decl_fchownat=yes} | : ${gl_cv_have_raw_decl_fcntl=yes} | : ${gl_cv_have_raw_decl_fdopendir=yes} | : ${gl_cv_have_raw_decl_ffsl=yes} | : ${gl_cv_have_raw_decl_ffsll=yes} | : ${gl_cv_have_raw_decl_fpurge=yes} | : ${gl_cv_have_raw_decl_fseeko=yes} | : ${gl_cv_have_raw_decl_fstat=yes} | : ${gl_cv_have_raw_decl_fstatat=yes} | : ${gl_cv_have_raw_decl_fsync=yes} | : ${gl_cv_have_raw_decl_ftello=yes} | : ${gl_cv_have_raw_decl_ftruncate=yes} | : ${gl_cv_have_raw_decl_getcwd=yes} | : ${gl_cv_have_raw_decl_getdelim=yes} | : ${gl_cv_have_raw_decl_getdomainname=yes} | : ${gl_cv_have_raw_decl_getdtablesize=yes} | : ${gl_cv_have_raw_decl_getgroups=yes} | : ${gl_cv_have_raw_decl_getdtablesize=yes} | : ${gl_cv_have_raw_decl_getgroups=yes} | : ${gl_cv_have_raw_decl_gethostname=yes} | : ${gl_cv_have_raw_decl_getline=yes} | : ${gl_cv_have_raw_decl_getloadavg=yes} | : ${gl_cv_have_raw_decl_getlogin=yes} | : ${gl_cv_have_raw_decl_getlogin_r=yes} | : ${gl_cv_have_raw_decl_getpagesize=yes} | : ${gl_cv_have_raw_decl_gets=yes} | : ${gl_cv_have_raw_decl_getsubopt=yes} | : ${gl_cv_have_raw_decl_gettimeofday=yes} | : ${gl_cv_have_raw_decl_getusershell=yes} | : ${gl_cv_have_raw_decl_grantpt=yes} | : ${gl_cv_have_raw_decl_imaxabs=yes} | : ${gl_cv_have_raw_decl_imaxdiv=yes} | : ${gl_cv_have_raw_decl_initstate=yes} | : ${gl_cv_have_raw_decl_isatty=yes} | : ${gl_cv_have_raw_decl_iswctype=yes} | : ${gl_cv_have_raw_decl_lchmod=yes} | : ${gl_cv_have_raw_decl_lchown=yes} | : ${gl_cv_have_raw_decl_link=yes} | : ${gl_cv_have_raw_decl_linkat=yes} | : ${gl_cv_have_raw_decl_lseek=yes} | : ${gl_cv_have_raw_decl_lstat=yes} | : ${gl_cv_have_raw_decl_mbrlen=yes} | : ${gl_cv_have_raw_decl_mbrtowc=yes} | : ${gl_cv_have_raw_decl_mbsinit=yes} | : ${gl_cv_have_raw_decl_mbsnrtowcs=yes} | : ${gl_cv_have_raw_decl_mbsrtowcs=yes} | : ${gl_cv_have_raw_decl_mkdirat=yes} | : ${gl_cv_have_raw_decl_mkdtemp=yes} | : ${gl_cv_have_raw_decl_mkfifo=yes} | : ${gl_cv_have_raw_decl_mkfifoat=yes} | : ${gl_cv_have_raw_decl_mknod=yes} | : ${gl_cv_have_raw_decl_mknodat=yes} | : ${gl_cv_have_raw_decl_mkstemp=yes} | : ${gl_cv_have_raw_decl_nl_langinfo=yes} | : ${gl_cv_have_raw_decl_openat=yes} | : ${gl_cv_have_raw_decl_opendir=yes} | : ${gl_cv_have_raw_decl_pclose=yes} | : ${gl_cv_have_raw_decl_pipe=yes} | : ${gl_cv_have_raw_decl_popen=yes} | : ${gl_cv_have_raw_decl_posix_openpt=yes} | : ${gl_cv_have_raw_decl_posix_spawn=yes} | : ${gl_cv_have_raw_decl_posix_openpt=yes} | : ${gl_cv_have_raw_decl_posix_spawn=yes} | : ${gl_cv_have_raw_decl_posix_spawn_file_actions_addclose=yes} | : ${gl_cv_have_raw_decl_posix_spawn_file_actions_adddup2=yes} | : ${gl_cv_have_raw_decl_posix_spawn_file_actions_addopen=yes} | : ${gl_cv_have_raw_decl_posix_spawn_file_actions_destroy=yes} | : ${gl_cv_have_raw_decl_posix_spawn_file_actions_init=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_destroy=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_getflags=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_getpgroup=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_getschedparam=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_getschedpolicy=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_getsigdefault=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_getsigmask=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_init=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_setflags=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_setpgroup=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_setschedparam=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_setschedpolicy=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_setsigdefault=yes} | : ${gl_cv_have_raw_decl_posix_spawnattr_setsigmask=yes} | : ${gl_cv_have_raw_decl_posix_spawnp=yes} | : ${gl_cv_have_raw_decl_pread=yes} | : ${gl_cv_have_raw_decl_pselect=yes} | : ${gl_cv_have_raw_decl_pthread_sigmask=yes} | : ${gl_cv_have_raw_decl_ptsname=yes} | : ${gl_cv_have_raw_decl_pwrite=yes} | : ${gl_cv_have_raw_decl_random=yes} | : ${gl_cv_have_raw_decl_readdir=yes} | : ${gl_cv_have_raw_decl_readlink=yes} | : ${gl_cv_have_raw_decl_readlinkat=yes} | : ${gl_cv_have_raw_decl_realpath=yes} | : ${gl_cv_have_raw_decl_renameat=yes} | : ${gl_cv_have_raw_decl_rewinddir=yes} | : ${gl_cv_have_raw_decl_rmdir=yes} | : ${gl_cv_have_raw_decl_rpmatch=yes} | : ${gl_cv_have_raw_decl_scandir=yes} | : ${gl_cv_have_raw_decl_select=yes} | : ${gl_cv_have_raw_decl_setenv=yes} | : ${gl_cv_have_raw_decl_sethostname=yes} | : ${gl_cv_have_raw_decl_setlocale=yes} | : ${gl_cv_have_raw_decl_setstate=yes} | : ${gl_cv_have_raw_decl_setusershell=yes} | : ${gl_cv_have_raw_decl_sigaction=yes} | : ${gl_cv_have_raw_decl_sigaddset=yes} | : ${gl_cv_have_raw_decl_sigdelset=yes} | : ${gl_cv_have_raw_decl_sigemptyset=yes} | : ${gl_cv_have_raw_decl_sigfillset=yes} | : ${gl_cv_have_raw_decl_sigismember=yes} | : ${gl_cv_have_raw_decl_sigpending=yes} | : ${gl_cv_have_raw_decl_sigprocmask=yes} | : ${gl_cv_have_raw_decl_sleep=yes} | : ${gl_cv_have_raw_decl_snprintf=yes} | : ${gl_cv_have_raw_decl_srandom=yes} | : ${gl_cv_have_raw_decl_stat=yes} | : ${gl_cv_have_raw_decl_strerror_r=yes} | : ${gl_cv_have_raw_decl_strtod=yes} | : ${gl_cv_have_raw_decl_strtoimax=yes} | : ${gl_cv_have_raw_decl_strtoll=yes} | : ${gl_cv_have_raw_decl_strtoull=yes} | : ${gl_cv_have_raw_decl_strtoumax=yes} | : ${gl_cv_have_raw_decl_symlink=yes} | : ${gl_cv_have_raw_decl_symlinkat=yes} | : ${gl_cv_have_raw_decl_tmpfile=yes} | : ${gl_cv_have_raw_decl_towctrans=yes} | : ${gl_cv_have_raw_decl_ttyname_r=yes} | : ${gl_cv_have_raw_decl_unlink=yes} | : ${gl_cv_have_raw_decl_unlinkat=yes} | : ${gl_cv_have_raw_decl_unlockpt=yes} | : ${gl_cv_have_raw_decl_unsetenv=yes} | : ${gl_cv_have_raw_decl_usleep=yes} | : ${gl_cv_have_raw_decl_vdprintf=yes} | : ${gl_cv_have_raw_decl_vsnprintf=yes} | : ${gl_cv_have_raw_decl_waitpid=yes} | : ${gl_cv_have_raw_decl_wcpcpy=yes} | : ${gl_cv_have_raw_decl_wcpncpy=yes} | : ${gl_cv_have_raw_decl_wcrtomb=yes} | : ${gl_cv_have_raw_decl_wcscasecmp=yes} | : ${gl_cv_have_raw_decl_wcscat=yes} | : ${gl_cv_have_raw_decl_wcschr=yes} | : ${gl_cv_have_raw_decl_wcscmp=yes} | : ${gl_cv_have_raw_decl_wcscoll=yes} | : ${gl_cv_have_raw_decl_wcscpy=yes} | : ${gl_cv_have_raw_decl_wcscspn=yes} | : ${gl_cv_have_raw_decl_wcsdup=yes} | : ${gl_cv_have_raw_decl_wcslen=yes} | : ${gl_cv_have_raw_decl_wcsncasecmp=yes} | : ${gl_cv_have_raw_decl_wcsncat=yes} | : ${gl_cv_have_raw_decl_wcsncmp=yes} | : ${gl_cv_have_raw_decl_wcsncpy=yes} | : ${gl_cv_have_raw_decl_wcsnlen=yes} | : ${gl_cv_have_raw_decl_wcsnrtombs=yes} | : ${gl_cv_have_raw_decl_wcspbrk=yes} | : ${gl_cv_have_raw_decl_wcsrchr=yes} | : ${gl_cv_have_raw_decl_wcsrtombs=yes} | : ${gl_cv_have_raw_decl_wcsspn=yes} | : ${gl_cv_have_raw_decl_wcsstr=yes} | : ${gl_cv_have_raw_decl_wcstok=yes} | : ${gl_cv_have_raw_decl_wcswidth=yes} | : ${gl_cv_have_raw_decl_wcsxfrm=yes} | : ${gl_cv_have_raw_decl_wctob=yes} | : ${gl_cv_have_raw_decl_wctrans=yes} | : ${gl_cv_have_raw_decl_wctype=yes} | : ${gl_cv_have_raw_decl_wcwidth=yes} | : ${gl_cv_have_raw_decl_wmemchr=yes} | : ${gl_cv_have_raw_decl_wmemcmp=yes} | : ${gl_cv_have_raw_decl_wmemcpy=yes} | : ${gl_cv_have_raw_decl_wmemmove=yes} | : ${gl_cv_have_raw_decl_wmemset=yes} | | : ${gl_cv_header_errno_h_complete=yes} | : ${gl_cv_header_inttypes_h=yes} | : ${gl_cv_header_langinfo_codeset=yes} | : ${gl_cv_header_langinfo_era=yes} | : ${gl_cv_header_langinfo_t_fmt_ampm=yes} | : ${gl_cv_header_langinfo_yesexpr=yes} | : ${gl_cv_header_locale_h_posix2001=yes} | : ${gl_cv_header_signal_h_SIGPIPE=yes} | : ${gl_cv_header_stdint_h=yes} | : ${gl_cv_header_sys_select_h_selfcontained=yes} | configure:2908: checking build system type configure:2922: result: amd64-portbld-freebsd9.3 configure:2942: checking host system type configure:2955: result: amd64-portbld-freebsd9.3 configure:2975: checking target system type configure:2988: result: amd64-portbld-freebsd9.3 configure:3031: checking for a BSD-compatible install configure:3099: result: /usr/bin/install -c -o root -g wheel configure:3110: checking whether build environment is sane configure:3165: result: yes configure:3316: checking for a thread-safe mkdir -p configure:3355: result: /bin/mkdir -p configure:3362: checking for gawk configure:3389: result: /usr/bin/awk configure:3400: checking whether gmake sets $(MAKE) configure:3422: result: yes configure:3525: checking whether gmake supports nested variables configure:3542: result: yes configure:3566: checking for style of include used by gmake configure:3594: result: GNU configure:3665: checking for gcc configure:3692: result: clang configure:3921: checking for C compiler version configure:3930: clang --version >&5 eval: clang: not found configure:3941: $? = 127 configure:3930: clang -v >&5 eval: clang: not found configure:3941: $? = 127 configure:3930: clang -V >&5 eval: clang: not found configure:3941: $? = 127 configure:3930: clang -qversion >&5 eval: clang: not found configure:3941: $? = 127 configure:3961: checking whether the C compiler works configure:3983: clang -O2 -pipe -fno-strict-aliasing -isystem/usr/local/include -Wl,-Y/usr/local/lib conftest.c >&5 eval: clang: not found configure:3987: $? = 127 configure:4025: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "Mesa" | #define PACKAGE_TARNAME "mesa" | #define PACKAGE_VERSION "9.1.7" | #define PACKAGE_STRING "Mesa 9.1.7" | #define PACKAGE_BUGREPORT "https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa" | #define PACKAGE_URL "" | #define PACKAGE "mesa" | #define VERSION "9.1.7" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:4030: error: in `/usr/ports/graphics/dri/work/Mesa-9.1.7': configure:4033: error: C compiler cannot create executables See `config.log' for more details ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=amd64-portbld-freebsd9.3 ac_cv_c_int16_t=yes ac_cv_c_int32_t=yes ac_cv_c_int64_t=yes ac_cv_c_int8_t=yes ac_cv_c_uint16_t=yes ac_cv_c_uint32_t=yes ac_cv_c_uint64_t=yes ac_cv_c_uint8_t=yes ac_cv_env_CCASFLAGS_set='' ac_cv_env_CCASFLAGS_value='' ac_cv_env_CCAS_set='' ac_cv_env_CCAS_value='' ac_cv_env_CCC_set='' ac_cv_env_CCC_value='' ac_cv_env_CC_set=set ac_cv_env_CC_value=clang ac_cv_env_CFLAGS_set=set ac_cv_env_CFLAGS_value='-O2 -pipe -fno-strict-aliasing' ac_cv_env_CPPFLAGS_set=set ac_cv_env_CPPFLAGS_value=-isystem/usr/local/include ac_cv_env_CPP_set=set ac_cv_env_CPP_value=clang-cpp ac_cv_env_CXXCPP_set='' ac_cv_env_CXXCPP_value='' ac_cv_env_CXXFLAGS_set=set ac_cv_env_CXXFLAGS_value='-O2 -pipe -fno-strict-aliasing' ac_cv_env_CXX_set=set ac_cv_env_CXX_value=clang++ ac_cv_env_DRI2PROTO_CFLAGS_set='' ac_cv_env_DRI2PROTO_CFLAGS_value='' ac_cv_env_DRI2PROTO_LIBS_set='' ac_cv_env_DRI2PROTO_LIBS_value='' ac_cv_env_DRIGL_CFLAGS_set='' ac_cv_env_DRIGL_CFLAGS_value='' ac_cv_env_DRIGL_LIBS_set='' ac_cv_env_DRIGL_LIBS_value='' ac_cv_env_GALLIUM_PIPE_LOADER_XCB_CFLAGS_set='' ac_cv_env_GALLIUM_PIPE_LOADER_XCB_CFLAGS_value='' ac_cv_env_GALLIUM_PIPE_LOADER_XCB_LIBS_set='' ac_cv_env_GALLIUM_PIPE_LOADER_XCB_LIBS_value='' ac_cv_env_GLPROTO_CFLAGS_set='' ac_cv_env_GLPROTO_CFLAGS_value='' ac_cv_env_GLPROTO_LIBS_set='' ac_cv_env_GLPROTO_LIBS_value='' ac_cv_env_INTEL_CFLAGS_set='' ac_cv_env_INTEL_CFLAGS_value='' ac_cv_env_INTEL_LIBS_set='' ac_cv_env_INTEL_LIBS_value='' ac_cv_env_LDFLAGS_set=set ac_cv_env_LDFLAGS_value=' -Wl,-Y/usr/local/lib' ac_cv_env_LIBDRM_CFLAGS_set='' ac_cv_env_LIBDRM_CFLAGS_value='' ac_cv_env_LIBDRM_LIBS_set='' ac_cv_env_LIBDRM_LIBS_value='' ac_cv_env_LIBDRM_XORG_CFLAGS_set='' ac_cv_env_LIBDRM_XORG_CFLAGS_value='' ac_cv_env_LIBDRM_XORG_LIBS_set='' ac_cv_env_LIBDRM_XORG_LIBS_value='' ac_cv_env_LIBKMS_XORG_CFLAGS_set='' ac_cv_env_LIBKMS_XORG_CFLAGS_value='' ac_cv_env_LIBKMS_XORG_LIBS_set='' ac_cv_env_LIBKMS_XORG_LIBS_value='' ac_cv_env_LIBS_set=set ac_cv_env_LIBS_value='' ac_cv_env_LIBUDEV_CFLAGS_set='' ac_cv_env_LIBUDEV_CFLAGS_value='' ac_cv_env_LIBUDEV_LIBS_set='' ac_cv_env_LIBUDEV_LIBS_value='' ac_cv_env_NOUVEAU_CFLAGS_set='' ac_cv_env_NOUVEAU_CFLAGS_value='' ac_cv_env_NOUVEAU_LIBS_set='' ac_cv_env_NOUVEAU_LIBS_value='' ac_cv_env_PKG_CONFIG_LIBDIR_set='' ac_cv_env_PKG_CONFIG_LIBDIR_value='' ac_cv_env_PKG_CONFIG_PATH_set='' ac_cv_env_PKG_CONFIG_PATH_value='' ac_cv_env_PKG_CONFIG_set=set ac_cv_env_PKG_CONFIG_value=pkgconf ac_cv_env_RADEON_CFLAGS_set='' ac_cv_env_RADEON_CFLAGS_value='' ac_cv_env_RADEON_LIBS_set='' ac_cv_env_RADEON_LIBS_value='' ac_cv_env_VDPAU_CFLAGS_set='' ac_cv_env_VDPAU_CFLAGS_value='' ac_cv_env_VDPAU_LIBS_set='' ac_cv_env_VDPAU_LIBS_value='' ac_cv_env_WAYLAND_CFLAGS_set='' ac_cv_env_WAYLAND_CFLAGS_value='' ac_cv_env_WAYLAND_LIBS_set='' ac_cv_env_WAYLAND_LIBS_value='' ac_cv_env_XCB_DRI2_CFLAGS_set='' ac_cv_env_XCB_DRI2_CFLAGS_value='' ac_cv_env_XCB_DRI2_LIBS_set='' ac_cv_env_XCB_DRI2_LIBS_value='' ac_cv_env_XEXT_CFLAGS_set='' ac_cv_env_XEXT_CFLAGS_value='' ac_cv_env_XEXT_LIBS_set='' ac_cv_env_XEXT_LIBS_value='' ac_cv_env_XF86VIDMODE_CFLAGS_set='' ac_cv_env_XF86VIDMODE_CFLAGS_value='' ac_cv_env_XF86VIDMODE_LIBS_set='' ac_cv_env_XF86VIDMODE_LIBS_value='' ac_cv_env_XLIBGL_CFLAGS_set='' ac_cv_env_XLIBGL_CFLAGS_value='' ac_cv_env_XLIBGL_LIBS_set='' ac_cv_env_XLIBGL_LIBS_value='' ac_cv_env_XORG_CFLAGS_set='' ac_cv_env_XORG_CFLAGS_value='' ac_cv_env_XORG_LIBS_set='' ac_cv_env_XORG_LIBS_value='' ac_cv_env_XVMC_CFLAGS_set='' ac_cv_env_XVMC_CFLAGS_value='' ac_cv_env_XVMC_LIBS_set='' ac_cv_env_XVMC_LIBS_value='' ac_cv_env_YACC_set='' ac_cv_env_YACC_value='' ac_cv_env_YFLAGS_set='' ac_cv_env_YFLAGS_value='' ac_cv_env_build_alias_set=set ac_cv_env_build_alias_value=amd64-portbld-freebsd9.3 ac_cv_env_host_alias_set='' ac_cv_env_host_alias_value='' ac_cv_env_target_alias_set='' ac_cv_env_target_alias_value='' ac_cv_func___b64_ntop=yes ac_cv_func___b64_pton=yes ac_cv_func__getlong=yes ac_cv_func__getshort=yes ac_cv_func__stat=yes ac_cv_func_acl_create_entry_np=yes ac_cv_func_acl_delete_def_file=yes ac_cv_func_acl_delete_fd_np=yes ac_cv_func_acl_delete_file_np=yes ac_cv_func_acl_free=yes ac_cv_func_acl_from_text=yes ac_cv_func_acl_get_fd=yes ac_cv_func_acl_get_file=yes ac_cv_func_acl_set_fd=yes ac_cv_func_acl_set_file=yes ac_cv_func_alarm=yes ac_cv_func_alloca=yes ac_cv_func_arc4random=yes ac_cv_func_arc4random_buf=yes ac_cv_func_arc4random_uniform=yes ac_cv_func_argz_count=no ac_cv_func_argz_next=no ac_cv_func_argz_stringify=no ac_cv_func_asprintf=yes ac_cv_func_atexit=yes ac_cv_func_bcmp=yes ac_cv_func_bcopy=yes ac_cv_func_bindresvport_sa=yes ac_cv_func_btowc=yes ac_cv_func_bzero=yes ac_cv_func_chown=yes ac_cv_func_clock=yes ac_cv_func_clock_gettime=yes ac_cv_func_closedir=yes ac_cv_func_closefrom=yes ac_cv_func_daemon=yes ac_cv_func_dirname=yes ac_cv_func_dlopen=yes ac_cv_func_dup2=yes ac_cv_func_eaccess=yes ac_cv_func_fchmod=yes ac_cv_func_fchown=yes ac_cv_func_fcntl=yes ac_cv_func_fileno=yes ac_cv_func_fork=yes ac_cv_func_fpurge=yes ac_cv_func_freeaddrinfo=yes ac_cv_func_fstatvfs=yes ac_cv_func_fsync=yes ac_cv_func_futimes=yes ac_cv_func_fwprintf=yes ac_cv_func_gai_strerror=yes ac_cv_func_getaddrinfo=yes ac_cv_func_getcwd=yes ac_cv_func_getdelim=yes ac_cv_func_getdtablesize=yes ac_cv_func_getegid=yes ac_cv_func_geteuid=yes ac_cv_func_getgid=yes ac_cv_func_getgrouplist=yes ac_cv_func_gethostbyname=yes ac_cv_func_gethostname=yes ac_cv_func_getline=yes ac_cv_func_getnameinfo=yes ac_cv_func_getopt=yes ac_cv_func_getopt_long_only=yes ac_cv_func_getpagesize=yes ac_cv_func_getpeereid=yes ac_cv_func_getpgid=yes ac_cv_func_getpgrp=yes ac_cv_func_getpgrp_void=yes ac_cv_func_getpid=yes ac_cv_func_getrlimit=yes ac_cv_func_getrusage=yes ac_cv_func_gettimeofday=yes ac_cv_func_getttyent=yes ac_cv_func_getuid=yes ac_cv_func_getwd=yes ac_cv_func_glob=yes ac_cv_func_group_from_gid=yes ac_cv_func_inet_aton=yes ac_cv_func_inet_ntoa=yes ac_cv_func_inet_ntop=yes ac_cv_func_innetgr=yes ac_cv_func_isascii=yes ac_cv_func_isblank=yes ac_cv_func_issetugid=yes ac_cv_func_iswblank=yes ac_cv_func_iswcntrl=yes ac_cv_func_iswctype=yes ac_cv_func_link=yes ac_cv_func_localtime=yes ac_cv_func_login_getcapbool=yes ac_cv_func_lstat=yes ac_cv_func_lstat_dereferences_slashed_symlink=yes ac_cv_func_malloc_0_nonnull=yes ac_cv_func_mbrlen=yes ac_cv_func_mbrtowc=yes ac_cv_func_mbsinit=yes ac_cv_func_mbsrtowcs=yes ac_cv_func_memchr=yes ac_cv_func_memcmp=yes ac_cv_func_memcpy=yes ac_cv_func_memmove=yes ac_cv_func_memset=yes ac_cv_func_mkdtemp=yes ac_cv_func_mkstemp=yes ac_cv_func_mktemp=yes ac_cv_func_mlock=yes ac_cv_func_mmap=yes ac_cv_func_mmap_fixed_mapped=yes ac_cv_func_mprotect=yes ac_cv_func_munlock=yes ac_cv_func_munmap=yes ac_cv_func_nl_langinfo=yes ac_cv_func_obstacks=no ac_cv_func_opendir=yes ac_cv_func_pam_getenvlist=yes ac_cv_func_pam_putenv=yes ac_cv_func_pathconf=yes ac_cv_func_pipe=yes ac_cv_func_poll=yes ac_cv_func_posix_spawn=yes ac_cv_func_pread=yes ac_cv_func_pstat_getdynamic=no ac_cv_func_pthread_cond_broadcast=yes ac_cv_func_pthread_cond_destroy=yes ac_cv_func_pthread_cond_init=yes ac_cv_func_pthread_cond_signal=yes ac_cv_func_pthread_cond_timedwait=yes ac_cv_func_pthread_cond_wait=yes ac_cv_func_pthread_equal=yes ac_cv_func_pthread_exit=yes ac_cv_func_pthread_mutex_destroy=yes ac_cv_func_pthread_mutex_init=yes ac_cv_func_pthread_mutex_lock=yes ac_cv_func_pthread_mutex_unlock=yes ac_cv_func_pthread_self=yes ac_cv_func_putenv=yes ac_cv_func_pwrite=yes ac_cv_func_raise=yes ac_cv_func_rand=yes ac_cv_func_random=yes ac_cv_func_rawmemchr=no ac_cv_func_readdir=yes ac_cv_func_readlink=yes ac_cv_func_readlinkat=yes ac_cv_func_readpassphrase=yes ac_cv_func_realpath=yes ac_cv_func_recvmsg=yes ac_cv_func_rename=yes ac_cv_func_rresvport_af=yes ac_cv_func_sched_yield=yes ac_cv_func_select=yes ac_cv_func_sendmsg=yes ac_cv_func_setegid=yes ac_cv_func_setenv=yes ac_cv_func_seteuid=yes ac_cv_func_setgroupent=yes ac_cv_func_setgroups=yes ac_cv_func_setlinebuf=yes ac_cv_func_setlocale=yes ac_cv_func_setlogin=yes ac_cv_func_setpassent=yes ac_cv_func_setproctitle=yes ac_cv_func_setregid=yes ac_cv_func_setresgid=yes ac_cv_func_setresuid=yes ac_cv_func_setreuid=yes ac_cv_func_setrlimit=yes ac_cv_func_setsid=yes ac_cv_func_setsockopt=yes ac_cv_func_setvbuf=yes ac_cv_func_shmget=yes ac_cv_func_sigaction=yes ac_cv_func_sigaltstack=yes ac_cv_func_siginterrupt=yes ac_cv_func_sigprocmask=yes ac_cv_func_sigvec=yes ac_cv_func_sleep=yes ac_cv_func_snprintf=yes ac_cv_func_socketpair=yes ac_cv_func_srand=yes ac_cv_func_srandom=yes ac_cv_func_stat=yes ac_cv_func_statfs=yes ac_cv_func_statvfs=yes ac_cv_func_stpcpy=yes ac_cv_func_stpncpy=yes ac_cv_func_strbrk=yes ac_cv_func_strcasecmp=yes ac_cv_func_strcspn=yes ac_cv_func_strdup=yes ac_cv_func_strerror=yes ac_cv_func_strerror_r=yes ac_cv_func_strftime=yes ac_cv_func_strlcat=yes ac_cv_func_strlcpy=yes ac_cv_func_strlen=yes ac_cv_func_strmode=yes ac_cv_func_strncasecmp=yes ac_cv_func_strndup=yes ac_cv_func_strnlen=yes ac_cv_func_strnlen_working=yes ac_cv_func_strpbrk=yes ac_cv_func_strptime=yes ac_cv_func_strsep=yes ac_cv_func_strsignal=yes ac_cv_func_strtol=yes ac_cv_func_strtoll=yes ac_cv_func_strtonum=yes ac_cv_func_strtoul=yes ac_cv_func_strtoull=yes ac_cv_func_symlink=yes ac_cv_func_sysconf=yes ac_cv_func_tcgetpgrp=yes ac_cv_func_time=yes ac_cv_func_towlower=yes ac_cv_func_truncate=yes ac_cv_func_tsearch=yes ac_cv_func_uname=yes ac_cv_func_unsetenv=yes ac_cv_func_user_from_uid=yes ac_cv_func_usleep=yes ac_cv_func_utime=yes ac_cv_func_utimes=yes ac_cv_func_vasprintf=yes ac_cv_func_vfork=yes ac_cv_func_vprintf=yes ac_cv_func_vsnprintf=yes ac_cv_func_vsprintf=yes ac_cv_func_waitpid=yes ac_cv_func_wcrtomb=yes ac_cv_func_wcscoll=yes ac_cv_func_wcslen=yes ac_cv_func_wcsnlen=yes ac_cv_func_wctob=yes ac_cv_func_wcwidth=yes ac_cv_func_wmemchr=yes ac_cv_func_wmemcpy=yes ac_cv_func_yield=no ac_cv_func_yp_match=yes ac_cv_have___va_copy=yes ac_cv_have_clock_t=yes ac_cv_have_control_in_msghdr=yes ac_cv_have_decl_GLOB_NOMATCH=yes ac_cv_have_decl_LLONG_MAX=yes ac_cv_have_decl_MAXSYMLINKS=yes ac_cv_have_decl_O_NONBLOCK=yes ac_cv_have_decl_RLIMIT_NPROC=yes ac_cv_have_decl_SHUT_RD=yes ac_cv_have_decl__Exit=yes ac_cv_have_decl_alarm=yes ac_cv_have_decl_alphasort=yes ac_cv_have_decl_atoll=yes ac_cv_have_decl_btowc=yes ac_cv_have_decl_chdir=yes ac_cv_have_decl_chown=yes ac_cv_have_decl_clearerr_unlocked=yes ac_cv_have_decl_closedir=yes ac_cv_have_decl_dprintf=yes ac_cv_have_decl_dup2=yes ac_cv_have_decl_dup=yes ac_cv_have_decl_endusershell=yes ac_cv_have_decl_faccessat=yes ac_cv_have_decl_fchdir=yes ac_cv_have_decl_fchmodat=yes ac_cv_have_decl_fchownat=yes ac_cv_have_decl_fcntl=yes ac_cv_have_decl_fdopendir=yes ac_cv_have_decl_feof_unlocked=yes ac_cv_have_decl_feof_unlocked_fgets_unlocked=yes ac_cv_have_decl_ferror_unlocked=yes ac_cv_have_decl_ffsl=yes ac_cv_have_decl_ffsll=yes ac_cv_have_decl_fpurge=yes ac_cv_have_decl_frexpl=yes ac_cv_have_decl_fseeko=yes ac_cv_have_decl_fstat=yes ac_cv_have_decl_fstatat=yes ac_cv_have_decl_fsync=yes ac_cv_have_decl_ftello=yes ac_cv_have_decl_ftruncate=yes ac_cv_have_decl_getc_unlocked=yes ac_cv_have_decl_getchar_unlocked=yes ac_cv_have_decl_getcwd=yes ac_cv_have_decl_getdelim=yes ac_cv_have_decl_getdomainname=yes ac_cv_have_decl_getdtablesize=yes ac_cv_have_decl_getenv=yes ac_cv_have_decl_getgroups=yes ac_cv_have_decl_gethostname=yes ac_cv_have_decl_getline=yes ac_cv_have_decl_getloadavg=yes ac_cv_have_decl_getlogin=yes ac_cv_have_decl_getlogin_r=yes ac_cv_have_decl_getpagesize=yes ac_cv_have_decl_gets=yes ac_cv_have_decl_getsubopt=yes ac_cv_have_decl_gettimeofday=yes ac_cv_have_decl_getusershell=yes ac_cv_have_decl_grantpt=yes ac_cv_have_decl_h_errno=yes ac_cv_have_decl_imaxabs=yes ac_cv_have_decl_imaxdiv=yes ac_cv_have_decl_initstate=yes ac_cv_have_decl_isatty=yes ac_cv_have_decl_isblank=yes ac_cv_have_decl_iswblank=yes ac_cv_have_decl_iswctype=yes ac_cv_have_decl_lchmod=yes ac_cv_have_decl_lchown=yes ac_cv_have_decl_link=yes ac_cv_have_decl_linkat=yes ac_cv_have_decl_lseek=yes ac_cv_have_decl_lstat=yes ac_cv_have_decl_mbrlen=yes ac_cv_have_decl_mbrtowc=yes ac_cv_have_decl_mbsinit=yes ac_cv_have_decl_mbsnrtowcs=yes ac_cv_have_decl_mbsrtowcs=yes ac_cv_have_decl_memmem=yes ac_cv_have_decl_memrchr=yes ac_cv_have_decl_mkdirat=yes ac_cv_have_decl_mkdtemp=yes ac_cv_have_decl_mkfifo=yes ac_cv_have_decl_mkfifoat=yes ac_cv_have_decl_mknod=yes ac_cv_have_decl_mknodat=yes ac_cv_have_decl_mkstemp=yes ac_cv_have_decl_nl_langinfo=yes ac_cv_have_decl_offsetof=yes ac_cv_have_decl_openat=yes ac_cv_have_decl_opendir=yes ac_cv_have_decl_pclose=yes ac_cv_have_decl_pipe=yes ac_cv_have_decl_popen=yes ac_cv_have_decl_posix_openpt=yes ac_cv_have_decl_posix_spawn=yes ac_cv_have_decl_posix_spawn_file_actions_addclose=yes ac_cv_have_decl_posix_spawn_file_actions_adddup2=yes ac_cv_have_decl_posix_spawn_file_actions_addopen=yes ac_cv_have_decl_posix_spawn_file_actions_destroy=yes ac_cv_have_decl_posix_spawn_file_actions_init=yes ac_cv_have_decl_posix_spawnattr_destroy=yes ac_cv_have_decl_posix_spawnattr_getflags=yes ac_cv_have_decl_posix_spawnattr_getpgroup=yes ac_cv_have_decl_posix_spawnattr_getschedparam=yes ac_cv_have_decl_posix_spawnattr_getschedpolicy=yes ac_cv_have_decl_posix_spawnattr_getsigdefault=yes ac_cv_have_decl_posix_spawnattr_getsigmask=yes ac_cv_have_decl_posix_spawnattr_init=yes ac_cv_have_decl_posix_spawnattr_setflags=yes ac_cv_have_decl_posix_spawnattr_setpgroup=yes ac_cv_have_decl_posix_spawnattr_setschedparam=yes ac_cv_have_decl_posix_spawnattr_setschedpolicy=yes ac_cv_have_decl_posix_spawnattr_setsigdefault=yes ac_cv_have_decl_posix_spawnattr_setsigmask=yes ac_cv_have_decl_posix_spawnp=yes ac_cv_have_decl_pread=yes ac_cv_have_decl_pselect=yes ac_cv_have_decl_pthread_sigmask=yes ac_cv_have_decl_ptsname=yes ac_cv_have_decl_putc_unlocked=yes ac_cv_have_decl_putchar_unlocked=yes ac_cv_have_decl_pwrite=yes ac_cv_have_decl_random=yes ac_cv_have_decl_rawmemchr=yes ac_cv_have_decl_readdir=yes ac_cv_have_decl_readlink=yes ac_cv_have_decl_readlinkat=yes ac_cv_have_decl_realpath=yes ac_cv_have_decl_renameat=yes ac_cv_have_decl_rewinddir=yes ac_cv_have_decl_rmdir=yes ac_cv_have_decl_rpmatch=yes ac_cv_have_decl_scandir=yes ac_cv_have_decl_select=yes ac_cv_have_decl_setenv=yes ac_cv_have_decl_sethostname=yes ac_cv_have_decl_setlocale=yes ac_cv_have_decl_setstate=yes ac_cv_have_decl_setusershell=yes ac_cv_have_decl_sigaction=yes ac_cv_have_decl_sigaddset=yes ac_cv_have_decl_sigaltstack=yes ac_cv_have_decl_sigdelset=yes ac_cv_have_decl_sigemptyset=yes ac_cv_have_decl_sigfillset=yes ac_cv_have_decl_sigismember=yes ac_cv_have_decl_sigpending=yes ac_cv_have_decl_sigprocmask=yes ac_cv_have_decl_sleep=yes ac_cv_have_decl_snprintf=yes ac_cv_have_decl_srandom=yes ac_cv_have_decl_stat=yes ac_cv_have_decl_stpcpy=yes ac_cv_have_decl_stpncpy=yes ac_cv_have_decl_strcasestr=yes ac_cv_have_decl_strdup=yes ac_cv_have_decl_strerror_r=yes ac_cv_have_decl_strncat=yes ac_cv_have_decl_strndup=yes ac_cv_have_decl_strnlen=yes ac_cv_have_decl_strpbrk=yes ac_cv_have_decl_strsep=yes ac_cv_have_decl_strsignal=yes ac_cv_have_decl_strtod=yes ac_cv_have_decl_strtoimax=yes ac_cv_have_decl_strtok_r=yes ac_cv_have_decl_strtoll=yes ac_cv_have_decl_strtoull=yes ac_cv_have_decl_strtoumax=yes ac_cv_have_decl_symlink=yes ac_cv_have_decl_symlinkat=yes ac_cv_have_decl_sys_siglist=yes ac_cv_have_decl_tcsendbreak=yes ac_cv_have_decl_tmpfile=yes ac_cv_have_decl_towctrans=yes ac_cv_have_decl_ttyname_r=yes ac_cv_have_decl_unlink=yes ac_cv_have_decl_unlinkat=yes ac_cv_have_decl_unlockpt=yes ac_cv_have_decl_unsetenv=yes ac_cv_have_decl_usleep=yes ac_cv_have_decl_vdprintf=yes ac_cv_have_decl_vsnprintf=yes ac_cv_have_decl_waitpid=yes ac_cv_have_decl_wcpcpy=yes ac_cv_have_decl_wcpncpy=yes ac_cv_have_decl_wcrtomb=yes ac_cv_have_decl_wcscasecmp=yes ac_cv_have_decl_wcscat=yes ac_cv_have_decl_wcschr=yes ac_cv_have_decl_wcscmp=yes ac_cv_have_decl_wcscoll=yes ac_cv_have_decl_wcscpy=yes ac_cv_have_decl_wcscspn=yes ac_cv_have_decl_wcsdup=yes ac_cv_have_decl_wcslen=yes ac_cv_have_decl_wcsncasecmp=yes ac_cv_have_decl_wcsncat=yes ac_cv_have_decl_wcsncmp=yes ac_cv_have_decl_wcsncpy=yes ac_cv_have_decl_wcsnlen=yes ac_cv_have_decl_wcsnrtombs=yes ac_cv_have_decl_wcspbrk=yes ac_cv_have_decl_wcsrchr=yes ac_cv_have_decl_wcsrtombs=yes ac_cv_have_decl_wcsspn=yes ac_cv_have_decl_wcsstr=yes ac_cv_have_decl_wcstok=yes ac_cv_have_decl_wcswidth=yes ac_cv_have_decl_wcsxfrm=yes ac_cv_have_decl_wctob=yes ac_cv_have_decl_wctrans=yes ac_cv_have_decl_wctype=yes ac_cv_have_decl_wcwidth=yes ac_cv_have_decl_wmemchr=yes ac_cv_have_decl_wmemcmp=yes ac_cv_have_decl_wmemcpy=yes ac_cv_have_decl_wmemmove=yes ac_cv_have_decl_wmemset=yes ac_cv_have_decl_writev=yes ac_cv_have_getopt_optreset=yes ac_cv_have_int64_t=yes ac_cv_have_intxx_t=yes ac_cv_have_mode_t=yes ac_cv_have_pid_t=yes ac_cv_have_pw_change_in_struct_passwd=yes ac_cv_have_pw_class_in_struct_passwd=yes ac_cv_have_pw_expire_in_struct_passwd=yes ac_cv_have_sa_family_t=yes ac_cv_have_size_t=yes ac_cv_have_ss_family_in_struct_ss=yes ac_cv_have_ssize_t=yes ac_cv_have_struct_addrinfo=yes ac_cv_have_struct_in6_addr=yes ac_cv_have_struct_sockaddr_in6=yes ac_cv_have_struct_sockaddr_storage=yes ac_cv_have_struct_timeval=yes ac_cv_have_u_char=yes ac_cv_have_u_int64_t=yes ac_cv_have_u_int=yes ac_cv_have_u_intxx_t=yes ac_cv_have_va_copy=yes ac_cv_header_alloca_h=no ac_cv_header_argz_h=no ac_cv_header_arpa_inet_h=yes ac_cv_header_arpa_nameser_h=yes ac_cv_header_byteswap_h=no ac_cv_header_ctype_h=yes ac_cv_header_dirent_h=yes ac_cv_header_dl_h=no ac_cv_header_dlfcn_h=yes ac_cv_header_elf_h=yes ac_cv_header_errno_h=yes ac_cv_header_fcntl_h=yes ac_cv_header_float_h=yes ac_cv_header_floatingpoint_h=yes ac_cv_header_getopt_h=yes ac_cv_header_glob_h=yes ac_cv_header_inttypes_h=yes ac_cv_header_langinfo_h=yes ac_cv_header_libgen_h=yes ac_cv_header_libutil_h=yes ac_cv_header_limits_h=yes ac_cv_header_login_cap_h=yes ac_cv_header_malloc_h=no ac_cv_header_math_h=yes ac_cv_header_memory_h=yes ac_cv_header_minix_config_h=no ac_cv_header_net_if_h=yes ac_cv_header_net_if_media_h=yes ac_cv_header_net_if_tap_h=yes ac_cv_header_net_if_tun_h=yes ac_cv_header_netdb_h=yes ac_cv_header_netinet_in_h=yes ac_cv_header_paths_h=yes ac_cv_header_poll_h=yes ac_cv_header_pwd_h=yes ac_cv_header_random_h=no ac_cv_header_readpassphrase_h=yes ac_cv_header_resolv_h=yes ac_cv_header_rpc_types_h=yes ac_cv_header_sched_h=yes ac_cv_header_search_h=yes ac_cv_header_security_pam_appl_h=yes ac_cv_header_signal_h=yes ac_cv_header_spawn_h=yes ac_cv_header_stdarg_h=yes ac_cv_header_stdbool_h=yes ac_cv_header_stdc=yes ac_cv_header_stddef_h=yes ac_cv_header_stdint_h=yes ac_cv_header_stdio_h=yes ac_cv_header_stdlib_h=yes ac_cv_header_string_h=yes ac_cv_header_strings_h=yes ac_cv_header_sys_acl_h=yes ac_cv_header_sys_cdefs_h=yes ac_cv_header_sys_dir_h=yes ac_cv_header_sys_fcntl_h=yes ac_cv_header_sys_file_h=yes ac_cv_header_sys_ioctl_h=yes ac_cv_header_sys_mman_h=yes ac_cv_header_sys_mount_h=yes ac_cv_header_sys_msg_h=yes ac_cv_header_sys_param_h=yes ac_cv_header_sys_poll_h=yes ac_cv_header_sys_ptrace_h=yes ac_cv_header_sys_select_h=yes ac_cv_header_sys_socket_h=yes ac_cv_header_sys_stat_h=yes ac_cv_header_sys_statvfs_h=yes ac_cv_header_sys_time_h=yes ac_cv_header_sys_timers_h=yes ac_cv_header_sys_times_h=yes ac_cv_header_sys_types_h=yes ac_cv_header_sys_un_h=yes ac_cv_header_sys_wait_h=yes ac_cv_header_time_h=yes ac_cv_header_ttyent_h=yes ac_cv_header_ucontext_h=yes ac_cv_header_unistd_h=yes ac_cv_header_utime_h=yes ac_cv_header_vfork_h=no ac_cv_header_vis_h=yes ac_cv_header_wchar_h=yes ac_cv_header_wctype_h=yes ac_cv_header_zlib_h=yes ac_cv_host=amd64-portbld-freebsd9.3 ac_cv_lib_crypt_crypt=yes ac_cv_lib_edit_el_init=yes ac_cv_lib_pam_pam_set_item=yes ac_cv_lib_z_deflate=yes ac_cv_libc_defines___progname=yes ac_cv_libc_defines_sys_errlist=yes ac_cv_libc_defines_sys_nerr=yes ac_cv_member_HEADER_ad=yes ac_cv_member_struct___res_state_retrans=yes ac_cv_member_struct_sigaction_sa_sigaction=yes ac_cv_member_struct_sockaddr_in6_sin6_scope_id=yes ac_cv_member_struct_stat_st_blksize=yes ac_cv_path_BZIP2=/usr/bin/bzip2 ac_cv_path_EGREP=/usr/bin/egrep ac_cv_path_FGREP=/usr/bin/fgrep ac_cv_path_GREP=/usr/bin/grep ac_cv_path_GZIP=/usr/bin/gzip ac_cv_path_MKTEMP_COMMAND=/usr/bin/mktemp ac_cv_path_SED=/usr/bin/sed ac_cv_path_install=/usr/bin/install ac_cv_path_mkdir=/bin/mkdir ac_cv_prog_AWK=/usr/bin/awk ac_cv_prog_LEX=/usr/local/bin/flex ac_cv_prog_SED=/usr/bin/sed ac_cv_prog_ac_ct_CC=clang ac_cv_prog_make_gmake_set=yes ac_cv_target=amd64-portbld-freebsd9.3 ac_cv_type__Bool=yes ac_cv_type_char=yes ac_cv_type_char_p=yes ac_cv_type_fsblkcnt_t=yes ac_cv_type_fsfilcnt_t=yes ac_cv_type_in_addr_t=yes ac_cv_type_in_port_t=yes ac_cv_type_int16_t=yes ac_cv_type_int32_t=yes ac_cv_type_int=yes ac_cv_type_intmax_t=yes ac_cv_type_long=yes ac_cv_type_long_double=yes ac_cv_type_long_long=yes ac_cv_type_long_long_int=yes ac_cv_type_mbstate_t=yes ac_cv_type_mode_t=yes ac_cv_type_nlink_t=yes ac_cv_type_off_t=yes ac_cv_type_pid_t=yes ac_cv_type_posix_spawn_file_actions_t=yes ac_cv_type_posix_spawnattr_t=yes ac_cv_type_ptrdiff_t=yes ac_cv_type_short=yes ac_cv_type_sig_atomic_t=yes ac_cv_type_sigset_t=yes ac_cv_type_size_t=yes ac_cv_type_socklen_t=yes ac_cv_type_ssize_t=yes ac_cv_type_stack_t=yes ac_cv_type_struct_timespec=yes ac_cv_type_u_char=yes ac_cv_type_u_int16_t=yes ac_cv_type_u_int32_t=yes ac_cv_type_u_int8_t=yes ac_cv_type_u_int=yes ac_cv_type_u_long=yes ac_cv_type_u_short=yes ac_cv_type_uid_t=yes ac_cv_type_uintptr_t=yes ac_cv_type_unsigned_char=yes ac_cv_type_unsigned_int=yes ac_cv_type_unsigned_long=yes ac_cv_type_unsigned_long_long=yes ac_cv_type_unsigned_long_long_int=yes ac_cv_type_unsigned_short=yes ac_cv_type_volatile_sig_atomic_t=yes ac_cv_type_wchar_t=yes ac_cv_type_wint_t=yes am_cv_make_support_nested_variables=yes am_cv_prog_tar_ustar=/usr/bin/tar cl_cv_prog_LN=/bin/ln cl_cv_prog_cp='/bin/cp -p' gl_cv_func_btowc_eof=yes gl_cv_func_btowc_nul=yes gl_cv_func_fcntl_f_dupfd_cloexec=yes gl_cv_func_fnmatch_posix=yes gl_cv_func_fopen_slash=yes gl_cv_func_frexp_no_libm=yes gl_cv_func_fseeko=yes gl_cv_func_ftello=yes gl_cv_func_getcwd_null=yes gl_cv_func_getcwd_posix_signature=yes gl_cv_func_getopt_posix=yes gl_cv_func_isnand_no_libm=yes gl_cv_func_ldexp_no_libm=yes gl_cv_func_lseek_pipe=yes gl_cv_func_lstat_dereferences_slashed_symlink=yes gl_cv_func_malloc_0_nonnull=1 gl_cv_func_malloc_posix=yes gl_cv_func_mbrtowc_incomplete_state=yes gl_cv_func_mbrtowc_nul_retval=yes gl_cv_func_mbrtowc_null_arg1=yes gl_cv_func_mbrtowc_null_arg2=yes gl_cv_func_mbrtowc_retval=yes gl_cv_func_mbrtowc_sanitycheck=yes gl_cv_func_open_slash=yes gl_cv_func_printf_directive_a=yes gl_cv_func_printf_directive_f=yes gl_cv_func_printf_directive_ls=yes gl_cv_func_printf_directive_n=yes gl_cv_func_printf_flag_grouping=yes gl_cv_func_printf_flag_leftadjust=yes gl_cv_func_printf_flag_zero=yes gl_cv_func_printf_infinite=yes gl_cv_func_printf_long_double=yes gl_cv_func_printf_positions=yes gl_cv_func_printf_precision=yes gl_cv_func_printf_sizes_c99=yes gl_cv_func_sigprocmask=1 gl_cv_func_snprintf_retval_c99=yes gl_cv_func_snprintf_size1=yes gl_cv_func_snprintf_usable=yes gl_cv_func_spawnattr_setschedparam=yes gl_cv_func_spawnattr_setschedpolicy=yes gl_cv_func_stat_dir_slash=yes gl_cv_func_stat_file_slash=yes gl_cv_func_stpncpy=yes gl_cv_func_va_copy=yes gl_cv_func_wcrtomb_retval=yes gl_cv_have_include_next=yes gl_cv_have_raw_decl__Exit=yes gl_cv_have_raw_decl_alphasort=yes gl_cv_have_raw_decl_atoll=yes gl_cv_have_raw_decl_btowc=yes gl_cv_have_raw_decl_chdir=yes gl_cv_have_raw_decl_chown=yes gl_cv_have_raw_decl_closedir=yes gl_cv_have_raw_decl_dprintf=yes gl_cv_have_raw_decl_dup2=yes gl_cv_have_raw_decl_dup=yes gl_cv_have_raw_decl_endusershell=yes gl_cv_have_raw_decl_faccessat=yes gl_cv_have_raw_decl_fchdir=yes gl_cv_have_raw_decl_fchmodat=yes gl_cv_have_raw_decl_fchownat=yes gl_cv_have_raw_decl_fcntl=yes gl_cv_have_raw_decl_fdopendir=yes gl_cv_have_raw_decl_ffsl=yes gl_cv_have_raw_decl_ffsll=yes gl_cv_have_raw_decl_fpurge=yes gl_cv_have_raw_decl_fseeko=yes gl_cv_have_raw_decl_fstat=yes gl_cv_have_raw_decl_fstatat=yes gl_cv_have_raw_decl_fsync=yes gl_cv_have_raw_decl_ftello=yes gl_cv_have_raw_decl_ftruncate=yes gl_cv_have_raw_decl_getcwd=yes gl_cv_have_raw_decl_getdelim=yes gl_cv_have_raw_decl_getdomainname=yes gl_cv_have_raw_decl_getdtablesize=yes gl_cv_have_raw_decl_getgroups=yes gl_cv_have_raw_decl_gethostname=yes gl_cv_have_raw_decl_getline=yes gl_cv_have_raw_decl_getloadavg=yes gl_cv_have_raw_decl_getlogin=yes gl_cv_have_raw_decl_getlogin_r=yes gl_cv_have_raw_decl_getpagesize=yes gl_cv_have_raw_decl_gets=yes gl_cv_have_raw_decl_getsubopt=yes gl_cv_have_raw_decl_gettimeofday=yes gl_cv_have_raw_decl_getusershell=yes gl_cv_have_raw_decl_grantpt=yes gl_cv_have_raw_decl_imaxabs=yes gl_cv_have_raw_decl_imaxdiv=yes gl_cv_have_raw_decl_initstate=yes gl_cv_have_raw_decl_isatty=yes gl_cv_have_raw_decl_iswctype=yes gl_cv_have_raw_decl_lchmod=yes gl_cv_have_raw_decl_lchown=yes gl_cv_have_raw_decl_link=yes gl_cv_have_raw_decl_linkat=yes gl_cv_have_raw_decl_lseek=yes gl_cv_have_raw_decl_lstat=yes gl_cv_have_raw_decl_mbrlen=yes gl_cv_have_raw_decl_mbrtowc=yes gl_cv_have_raw_decl_mbsinit=yes gl_cv_have_raw_decl_mbsnrtowcs=yes gl_cv_have_raw_decl_mbsrtowcs=yes gl_cv_have_raw_decl_memcpy=no gl_cv_have_raw_decl_memmem=yes gl_cv_have_raw_decl_memrchr=yes gl_cv_have_raw_decl_mkdirat=yes gl_cv_have_raw_decl_mkdtemp=yes gl_cv_have_raw_decl_mkfifo=yes gl_cv_have_raw_decl_mkfifoat=yes gl_cv_have_raw_decl_mknod=yes gl_cv_have_raw_decl_mknodat=yes gl_cv_have_raw_decl_mkstemp=yes gl_cv_have_raw_decl_nl_langinfo=yes gl_cv_have_raw_decl_openat=yes gl_cv_have_raw_decl_opendir=yes gl_cv_have_raw_decl_pclose=yes gl_cv_have_raw_decl_pipe=yes gl_cv_have_raw_decl_popen=yes gl_cv_have_raw_decl_posix_openpt=yes gl_cv_have_raw_decl_posix_spawn=yes gl_cv_have_raw_decl_posix_spawn_file_actions_addclose=yes gl_cv_have_raw_decl_posix_spawn_file_actions_adddup2=yes gl_cv_have_raw_decl_posix_spawn_file_actions_addopen=yes gl_cv_have_raw_decl_posix_spawn_file_actions_destroy=yes gl_cv_have_raw_decl_posix_spawn_file_actions_init=yes gl_cv_have_raw_decl_posix_spawnattr_destroy=yes gl_cv_have_raw_decl_posix_spawnattr_getflags=yes gl_cv_have_raw_decl_posix_spawnattr_getpgroup=yes gl_cv_have_raw_decl_posix_spawnattr_getschedparam=yes gl_cv_have_raw_decl_posix_spawnattr_getschedpolicy=yes gl_cv_have_raw_decl_posix_spawnattr_getsigdefault=yes gl_cv_have_raw_decl_posix_spawnattr_getsigmask=yes gl_cv_have_raw_decl_posix_spawnattr_init=yes gl_cv_have_raw_decl_posix_spawnattr_setflags=yes gl_cv_have_raw_decl_posix_spawnattr_setpgroup=yes gl_cv_have_raw_decl_posix_spawnattr_setschedparam=yes gl_cv_have_raw_decl_posix_spawnattr_setschedpolicy=yes gl_cv_have_raw_decl_posix_spawnattr_setsigdefault=yes gl_cv_have_raw_decl_posix_spawnattr_setsigmask=yes gl_cv_have_raw_decl_posix_spawnp=yes gl_cv_have_raw_decl_pread=yes gl_cv_have_raw_decl_pselect=yes gl_cv_have_raw_decl_pthread_sigmask=yes gl_cv_have_raw_decl_ptsname=yes gl_cv_have_raw_decl_pwrite=yes gl_cv_have_raw_decl_random=yes gl_cv_have_raw_decl_rawmemchr=yes gl_cv_have_raw_decl_readdir=yes gl_cv_have_raw_decl_readlink=yes gl_cv_have_raw_decl_readlinkat=yes gl_cv_have_raw_decl_realpath=yes gl_cv_have_raw_decl_renameat=yes gl_cv_have_raw_decl_rewinddir=yes gl_cv_have_raw_decl_rmdir=yes gl_cv_have_raw_decl_rpmatch=yes gl_cv_have_raw_decl_scandir=yes gl_cv_have_raw_decl_select=yes gl_cv_have_raw_decl_setenv=yes gl_cv_have_raw_decl_sethostname=yes gl_cv_have_raw_decl_setlocale=yes gl_cv_have_raw_decl_setstate=yes gl_cv_have_raw_decl_setusershell=yes gl_cv_have_raw_decl_sigaction=yes gl_cv_have_raw_decl_sigaddset=yes gl_cv_have_raw_decl_sigdelset=yes gl_cv_have_raw_decl_sigemptyset=yes gl_cv_have_raw_decl_sigfillset=yes gl_cv_have_raw_decl_sigismember=yes gl_cv_have_raw_decl_sigpending=yes gl_cv_have_raw_decl_sigprocmask=yes gl_cv_have_raw_decl_sleep=yes gl_cv_have_raw_decl_snprintf=yes gl_cv_have_raw_decl_srandom=yes gl_cv_have_raw_decl_stat=yes gl_cv_have_raw_decl_stpcpy=yes gl_cv_have_raw_decl_stpncpy=yes gl_cv_have_raw_decl_strcasestr=yes gl_cv_have_raw_decl_strdup=yes gl_cv_have_raw_decl_strerror_r=yes gl_cv_have_raw_decl_strncat=yes gl_cv_have_raw_decl_strndup=yes gl_cv_have_raw_decl_strnlen=yes gl_cv_have_raw_decl_strpbrk=yes gl_cv_have_raw_decl_strsep=yes gl_cv_have_raw_decl_strsignal=yes gl_cv_have_raw_decl_strtod=yes gl_cv_have_raw_decl_strtoimax=yes gl_cv_have_raw_decl_strtok_r=yes gl_cv_have_raw_decl_strtoll=yes gl_cv_have_raw_decl_strtoull=yes gl_cv_have_raw_decl_strtoumax=yes gl_cv_have_raw_decl_strverscmp=no gl_cv_have_raw_decl_symlink=yes gl_cv_have_raw_decl_symlinkat=yes gl_cv_have_raw_decl_tmpfile=yes gl_cv_have_raw_decl_towctrans=yes gl_cv_have_raw_decl_ttyname_r=yes gl_cv_have_raw_decl_unlink=yes gl_cv_have_raw_decl_unlinkat=yes gl_cv_have_raw_decl_unlockpt=yes gl_cv_have_raw_decl_unsetenv=yes gl_cv_have_raw_decl_usleep=yes gl_cv_have_raw_decl_vdprintf=yes gl_cv_have_raw_decl_vsnprintf=yes gl_cv_have_raw_decl_waitpid=yes gl_cv_have_raw_decl_wcpcpy=yes gl_cv_have_raw_decl_wcpncpy=yes gl_cv_have_raw_decl_wcrtomb=yes gl_cv_have_raw_decl_wcscasecmp=yes gl_cv_have_raw_decl_wcscat=yes gl_cv_have_raw_decl_wcschr=yes gl_cv_have_raw_decl_wcscmp=yes gl_cv_have_raw_decl_wcscoll=yes gl_cv_have_raw_decl_wcscpy=yes gl_cv_have_raw_decl_wcscspn=yes gl_cv_have_raw_decl_wcsdup=yes gl_cv_have_raw_decl_wcslen=yes gl_cv_have_raw_decl_wcsncasecmp=yes gl_cv_have_raw_decl_wcsncat=yes gl_cv_have_raw_decl_wcsncmp=yes gl_cv_have_raw_decl_wcsncpy=yes gl_cv_have_raw_decl_wcsnlen=yes gl_cv_have_raw_decl_wcsnrtombs=yes gl_cv_have_raw_decl_wcspbrk=yes gl_cv_have_raw_decl_wcsrchr=yes gl_cv_have_raw_decl_wcsrtombs=yes gl_cv_have_raw_decl_wcsspn=yes gl_cv_have_raw_decl_wcsstr=yes gl_cv_have_raw_decl_wcstok=yes gl_cv_have_raw_decl_wcswidth=yes gl_cv_have_raw_decl_wcsxfrm=yes gl_cv_have_raw_decl_wctob=yes gl_cv_have_raw_decl_wctrans=yes gl_cv_have_raw_decl_wctype=yes gl_cv_have_raw_decl_wcwidth=yes gl_cv_have_raw_decl_wmemchr=yes gl_cv_have_raw_decl_wmemcmp=yes gl_cv_have_raw_decl_wmemcpy=yes gl_cv_have_raw_decl_wmemmove=yes gl_cv_have_raw_decl_wmemset=yes gl_cv_header_errno_h_complete=yes gl_cv_header_inttypes_h=yes gl_cv_header_langinfo_codeset=yes gl_cv_header_langinfo_era=yes gl_cv_header_langinfo_t_fmt_ampm=yes gl_cv_header_langinfo_yesexpr=yes gl_cv_header_locale_h_posix2001=yes gl_cv_header_signal_h_SIGPIPE=yes gl_cv_header_stdint_h=yes gl_cv_header_sys_select_h_selfcontained=yes gl_cv_header_wchar_h_correct_inline=yes gl_cv_sigaltstack_low_base=yes gl_cv_size_max=yes gl_cv_sys_struct_timespec_in_time_h=yes gl_cv_sys_struct_timeval=yes gl_cv_type_sigset_t=yes gl_cv_type_wchar_t_signed=yes gl_cv_type_wctrans_t=yes gl_cv_type_wctype_t=yes gl_cv_type_wint_t_signed=yes gl_cv_var_stdin_large_offset=yes gt_cv_c_intmax_t=yes gt_cv_c_wchar_t=yes gt_cv_c_wint_t=yes gt_cv_func_printf_posix=yes gt_cv_func_unsetenv_ret=int gt_cv_int_divbyzero_sigfpe=yes gt_cv_siginfo_t=yes gt_cv_ssize_t=yes lt_cv_path_MAGIC_CMD=/usr/bin/file lt_cv_sys_max_cmd_len=262144 ## ----------------- ## ## Output variables. ## ## ----------------- ## ACLOCAL='${SHELL} /usr/ports/graphics/dri/work/Mesa-9.1.7/bin/missing --run aclocal-1.12' AMDEPBACKSLASH='\' AMDEP_FALSE='#' AMDEP_TRUE='' AMTAR='$${TAR-tar}' AM_BACKSLASH='\' AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)' AM_DEFAULT_VERBOSITY='0' AM_V='$(V)' API_DEFINES='' AR='' AUTOCONF='${SHELL} /usr/ports/graphics/dri/work/Mesa-9.1.7/bin/missing --run autoconf' AUTOHEADER='${SHELL} /usr/ports/graphics/dri/work/Mesa-9.1.7/bin/missing --run autoheader' AUTOMAKE='${SHELL} /usr/ports/graphics/dri/work/Mesa-9.1.7/bin/missing --run automake-1.12' AWK='/usr/bin/awk' BUILD_EXEEXT='' BUILD_OBJEXT='' BUILD_SHARED_FALSE='' BUILD_SHARED_TRUE='' CC='clang' CCAS='' CCASDEPMODE='' CCASFLAGS='' CCDEPMODE='' CC_FOR_BUILD='' CFLAGS='-O2 -pipe -fno-strict-aliasing' CFLAGS_FOR_BUILD='' CLANG_RESOURCE_DIR='' CLOCK_LIB='' CPP='clang-cpp' CPPFLAGS='-isystem/usr/local/include' CPPFLAGS_FOR_BUILD='' CPP_FOR_BUILD='' CROSS_COMPILING_FALSE='' CROSS_COMPILING_TRUE='' CXX='clang++' CXXCPP='' CXXCPPFLAGS_FOR_BUILD='' CXXCPP_FOR_BUILD='' CXXDEPMODE='' CXXFLAGS='-O2 -pipe -fno-strict-aliasing' CXXFLAGS_FOR_BUILD='' CXX_FOR_BUILD='' CYGPATH_W='echo' DEFINES='' DEFINES_FOR_BUILD='' DEFS='' DEPDIR='.deps' DLLTOOL='' DLOPEN_LIBS='' DRI2PROTO_CFLAGS='' DRI2PROTO_LIBS='' DRIGL_CFLAGS='' DRIGL_LIBS='' DRIVER_DIRS='' DRI_DIRS='' DRI_DRIVER_INSTALL_DIR='' DRI_DRIVER_SEARCH_DIR='' DRI_LIB_DEPS='' DRI_PC_REQ_PRIV='' DSYMUTIL='' DUMPBIN='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGL_CFLAGS='' EGL_CLIENT_APIS='' EGL_DRIVER_INSTALL_DIR='' EGL_LIB_DEPS='' EGL_LIB_GLOB='' EGL_LIB_NAME='' EGL_NATIVE_PLATFORM='' EGL_PLATFORMS='' EGREP='' EXEEXT='' EXPAT_INCLUDES='' FGREP='' GALLIUM_DIRS='' GALLIUM_DRIVERS_DIRS='' GALLIUM_DRI_LIB_DEPS='' GALLIUM_MAKE_DIRS='' GALLIUM_PIPE_LOADER_DEFINES='' GALLIUM_PIPE_LOADER_LIBS='' GALLIUM_PIPE_LOADER_XCB_CFLAGS='' GALLIUM_PIPE_LOADER_XCB_LIBS='' GALLIUM_STATE_TRACKERS_DIRS='' GALLIUM_TARGET_DIRS='' GALLIUM_WINSYS_DIRS='' GBM_PC_LIB_PRIV='' GBM_PC_REQ_PRIV='' GLAPI_LIB_GLOB='' GLAPI_LIB_NAME='' GLESv1_CM_LIB_DEPS='' GLESv1_CM_LIB_GLOB='' GLESv1_CM_LIB_NAME='' GLESv1_CM_PC_LIB_PRIV='' GLESv2_LIB_DEPS='' GLESv2_LIB_GLOB='' GLESv2_LIB_NAME='' GLESv2_PC_LIB_PRIV='' GLPROTO_CFLAGS='' GLPROTO_LIBS='' GLX_TLS='' GL_LIB='' GL_LIB_DEPS='' GL_LIB_GLOB='' GL_LIB_NAME='' GL_PC_CFLAGS='' GL_PC_LIB_PRIV='' GL_PC_REQ_PRIV='' GREP='' HAVE_COMMON_DRI_FALSE='' HAVE_COMMON_DRI_TRUE='' HAVE_DRI_FALSE='' HAVE_DRI_TRUE='' HAVE_DRM_LOADER_GALLIUM_FALSE='' HAVE_DRM_LOADER_GALLIUM_TRUE='' HAVE_EGL_DRIVER_DRI2_FALSE='' HAVE_EGL_DRIVER_DRI2_TRUE='' HAVE_EGL_DRIVER_GLX_FALSE='' HAVE_EGL_DRIVER_GLX_TRUE='' HAVE_EGL_PLATFORM_DRM_FALSE='' HAVE_EGL_PLATFORM_DRM_TRUE='' HAVE_EGL_PLATFORM_FBDEV_FALSE='' HAVE_EGL_PLATFORM_FBDEV_TRUE='' HAVE_EGL_PLATFORM_NULL_FALSE='' HAVE_EGL_PLATFORM_NULL_TRUE='' HAVE_EGL_PLATFORM_WAYLAND_FALSE='' HAVE_EGL_PLATFORM_WAYLAND_TRUE='' HAVE_EGL_PLATFORM_X11_FALSE='' HAVE_EGL_PLATFORM_X11_TRUE='' HAVE_GALAHAD_GALLIUM_FALSE='' HAVE_GALAHAD_GALLIUM_TRUE='' HAVE_GALLIUM_COMPUTE_FALSE='' HAVE_GALLIUM_COMPUTE_TRUE='' HAVE_GALLIUM_FALSE='' HAVE_GALLIUM_I915_FALSE='' HAVE_GALLIUM_I915_TRUE='' HAVE_GALLIUM_LLVMPIPE_FALSE='' HAVE_GALLIUM_LLVMPIPE_TRUE='' HAVE_GALLIUM_NOUVEAU_FALSE='' HAVE_GALLIUM_NOUVEAU_TRUE='' HAVE_GALLIUM_R300_FALSE='' HAVE_GALLIUM_R300_TRUE='' HAVE_GALLIUM_R600_FALSE='' HAVE_GALLIUM_R600_TRUE='' HAVE_GALLIUM_RADEONSI_FALSE='' HAVE_GALLIUM_RADEONSI_TRUE='' HAVE_GALLIUM_SOFTPIPE_FALSE='' HAVE_GALLIUM_SOFTPIPE_TRUE='' HAVE_GALLIUM_SVGA_FALSE='' HAVE_GALLIUM_SVGA_TRUE='' HAVE_GALLIUM_TRUE='' HAVE_I915_DRI_FALSE='' HAVE_I915_DRI_TRUE='' HAVE_I965_DRI_FALSE='' HAVE_I965_DRI_TRUE='' HAVE_IDENTITY_GALLIUM_FALSE='' HAVE_IDENTITY_GALLIUM_TRUE='' HAVE_LOADER_GALLIUM_FALSE='' HAVE_LOADER_GALLIUM_TRUE='' HAVE_MESA_LLVM_FALSE='' HAVE_MESA_LLVM_TRUE='' HAVE_NOOP_GALLIUM_FALSE='' HAVE_NOOP_GALLIUM_TRUE='' HAVE_NOUVEAU_DRI_FALSE='' HAVE_NOUVEAU_DRI_TRUE='' HAVE_OPENGL_FALSE='' HAVE_OPENGL_TRUE='' HAVE_OPENVG_FALSE='' HAVE_OPENVG_TRUE='' HAVE_R200_DRI_FALSE='' HAVE_R200_DRI_TRUE='' HAVE_RADEON_DRI_FALSE='' HAVE_RADEON_DRI_TRUE='' HAVE_SHARED_GLAPI_FALSE='' HAVE_SHARED_GLAPI_TRUE='' HAVE_SPARC_ASM_FALSE='' HAVE_SPARC_ASM_TRUE='' HAVE_SWRAST_DRI_FALSE='' HAVE_SWRAST_DRI_TRUE='' HAVE_X11_DRIVER_FALSE='' HAVE_X11_DRIVER_TRUE='' HAVE_X86_64_ASM_FALSE='' HAVE_X86_64_ASM_TRUE='' HAVE_X86_ASM_FALSE='' HAVE_X86_ASM_TRUE='' HAVE_XF86VIDMODE='' HAVE_XF86VIDMODE_FALSE='' HAVE_XF86VIDMODE_TRUE='' INDENT='' INDENT_FLAGS='' INSTALL_DATA='install -o root -g wheel -m 0644' INSTALL_PROGRAM='install -s -o root -g wheel -m 555' INSTALL_SCRIPT='install -o root -g wheel -m 555' INSTALL_STRIP_PROGRAM='$(install_sh) -c -s' INTEL_CFLAGS='' INTEL_LIBS='' LD='' LDFLAGS=' -Wl,-Y/usr/local/lib' LDFLAGS_FOR_BUILD='' LEX='' LEXLIB='' LEX_OUTPUT_ROOT='' LIBCLC_INCLUDEDIR='' LIBCLC_LIBEXECDIR='' LIBDRM_CFLAGS='' LIBDRM_LIBS='' LIBDRM_XORG_CFLAGS='' LIBDRM_XORG_LIBS='' LIBKMS_XORG_CFLAGS='' LIBKMS_XORG_LIBS='' LIBOBJS='' LIBS='' LIBTOOL='' LIBUDEV_CFLAGS='' LIBUDEV_LIBS='' LIB_DIR='' LIPO='' LLVM_BINDIR='' LLVM_CFLAGS='' LLVM_CONFIG='/usr/local/bin/llvm-config33' LLVM_CPPFLAGS='' LLVM_CXXFLAGS='' LLVM_INCLUDEDIR='' LLVM_LDFLAGS='' LLVM_LIBDIR='' LLVM_LIBS='' LLVM_NEEDS_FNORTTI_FALSE='' LLVM_NEEDS_FNORTTI_TRUE='' LLVM_VERSION='' LN_S='' LTLIBOBJS='' MAKE='gmake' MAKEINFO='${SHELL} /usr/ports/graphics/dri/work/Mesa-9.1.7/bin/missing --run makeinfo' MANIFEST_TOOL='' MESA_ASM_FILES='' MESA_LLVM='' MKDIR_P='/bin/mkdir -p' NEED_LIBDRICORE_FALSE='' NEED_LIBDRICORE_TRUE='' NEED_LIBMESA_FALSE='' NEED_LIBMESA_TRUE='' NEED_LIBPROGRAM_FALSE='' NEED_LIBPROGRAM_TRUE='' NEED_RADEON_GALLIUM_FALSE='' NEED_RADEON_GALLIUM_TRUE='' NM='' NMEDIT='' NOUVEAU_CFLAGS='' NOUVEAU_LIBS='' OBJDUMP='' OBJEXT='' OPENCL_LIB_INSTALL_DIR='' OSMESA_LIB='' OSMESA_LIB_DEPS='' OSMESA_LIB_NAME='' OSMESA_MESA_DEPS='' OSMESA_PC_LIB_PRIV='' OSMESA_PC_REQ='' OSMESA_VERSION='' OTOOL64='' OTOOL='' PACKAGE='mesa' PACKAGE_BUGREPORT='https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa' PACKAGE_NAME='Mesa' PACKAGE_STRING='Mesa 9.1.7' PACKAGE_TARNAME='mesa' PACKAGE_URL='' PACKAGE_VERSION='9.1.7' PATH_SEPARATOR=':' PERL='' PKG_CONFIG='pkgconf' PKG_CONFIG_LIBDIR='' PKG_CONFIG_PATH='' POSIX_SHELL='' PTHREAD_CC='' PTHREAD_CFLAGS='' PTHREAD_LIBS='' PYTHON2='' R600_NEED_RADEON_GALLIUM_FALSE='' R600_NEED_RADEON_GALLIUM_TRUE='' RADEON_CFLAGS='' RADEON_LIBS='' RANLIB='' SED='' SELINUX_LIBS='' SET_MAKE='' SHELL='/bin/sh' SRC_DIRS='' STRIP='' USE_R600_LLVM_COMPILER_FALSE='' USE_R600_LLVM_COMPILER_TRUE='' VDPAU_CFLAGS='' VDPAU_LIBS='' VDPAU_LIB_INSTALL_DIR='' VDPAU_MAJOR='' VDPAU_MINOR='' VERSION='9.1.7' VG_LIB_DEPS='' VG_LIB_GLOB='' VG_LIB_NAME='' VG_PC_LIB_PRIV='' VISIBILITY_CFLAGS='' VISIBILITY_CXXFLAGS='' WAYLAND_CFLAGS='' WAYLAND_LIBS='' WAYLAND_SCANNER='' X11_INCLUDES='' XA_MAJOR='' XA_MINOR='' XA_TINY='' XA_VERSION='' XCB_DRI2_CFLAGS='' XCB_DRI2_LIBS='' XEXT_CFLAGS='' XEXT_LIBS='' XF86VIDMODE_CFLAGS='' XF86VIDMODE_LIBS='' XLIBGL_CFLAGS='' XLIBGL_LIBS='' XORG_CFLAGS='' XORG_DRIVER_INSTALL_DIR='' XORG_LIBS='' XVMC_CFLAGS='' XVMC_LIBS='' XVMC_LIB_INSTALL_DIR='' XVMC_MAJOR='' XVMC_MINOR='' YACC='' YFLAGS='' ac_ct_AR='' ac_ct_CC='clang' ac_ct_CC_FOR_BUILD='' ac_ct_CXX='' ac_ct_CXX_FOR_BUILD='' ac_ct_DUMPBIN='' am__EXEEXT_FALSE='' am__EXEEXT_TRUE='' am__fastdepCCAS_FALSE='' am__fastdepCCAS_TRUE='' am__fastdepCC_FALSE='' am__fastdepCC_TRUE='' am__fastdepCXX_FALSE='' am__fastdepCXX_TRUE='' am__include='include' am__isrc='' am__leading_dot='.' am__nodep='_no' am__quote='' am__tar='$${TAR-tar} chof - "$$tardir"' am__untar='$${TAR-tar} xf -' ax_pthread_config='' bindir='${exec_prefix}/bin' build='amd64-portbld-freebsd9.3' build_alias='amd64-portbld-freebsd9.3' build_cpu='amd64' build_os='freebsd9.3' build_vendor='portbld' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='NONE' host='amd64-portbld-freebsd9.3' host_alias='' host_cpu='amd64' host_os='freebsd9.3' host_vendor='portbld' htmldir='${docdir}' includedir='${prefix}/include' infodir='/usr/local/info' install_sh='${SHELL} /usr/ports/graphics/dri/work/Mesa-9.1.7/bin/install-sh' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='/usr/local/man' mkdir_p='$(MKDIR_P)' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/usr/local' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target='amd64-portbld-freebsd9.3' target_alias='' target_cpu='amd64' target_os='freebsd9.3' target_vendor='portbld' ## ----------- ## ## confdefs.h. ## ## ----------- ## /* confdefs.h */ #define PACKAGE_NAME "Mesa" #define PACKAGE_TARNAME "mesa" #define PACKAGE_VERSION "9.1.7" #define PACKAGE_STRING "Mesa 9.1.7" #define PACKAGE_BUGREPORT "https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa" #define PACKAGE_URL "" #define PACKAGE "mesa" #define VERSION "9.1.7" configure: exit 77 ------=_20140928151148_51632-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 22:31:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D15A5847 for ; Sun, 28 Sep 2014 22:31:19 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 91A3AC7 for ; Sun, 28 Sep 2014 22:31:18 +0000 (UTC) Received: from [172.16.0.55] (unknown [92.247.20.226]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id ABB3F547FE for ; Sun, 28 Sep 2014 22:31:16 +0000 (UTC) Message-ID: <54288C32.3080201@freebsd.org> Date: Sun, 28 Sep 2014 18:31:14 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Mesa-9: configure: error: C compiler cannot create executables References: <7b0a119ebc4d8d7813f92c0f94aba8d8.authenticated@ultimatedns.net> <542882B7.4060407@freebsd.org> <82259777bbe474bb5581c2b4a0b79f25.authenticated@ultimatedns.net> In-Reply-To: <82259777bbe474bb5581c2b4a0b79f25.authenticated@ultimatedns.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 22:31:20 -0000 On 09/28/2014 18:11, Chris H wrote: >> On 09/28/2014 17:37, Chris H wrote: >>> Greetings, >>> A recent install of RELENG_9, followed by a build|install world|kernel. >>> Returns the following error when attempting an make install of >>> x11/xorg-minimal >>> >>> ===> Configuring for dri-9.1.7_5,2 >>> configure: loading site script /usr/ports/Templates/config.site >>> checking build system type... amd64-portbld-freebsd9.3 >>> checking host system type... amd64-portbld-freebsd9.3 >>> checking target system type... amd64-portbld-freebsd9.3 >>> checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel >>> checking whether build environment is sane... yes >>> checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p >>> checking for gawk... (cached) /usr/bin/awk >>> checking whether gmake sets $(MAKE)... yes >>> checking whether gmake supports nested variables... yes >>> checking for style of include used by gmake... GNU >>> checking for gcc... clang >>> checking whether the C compiler works... no >>> configure: error: in `/usr/ports/graphics/dri/work/Mesa-9.1.7': >>> configure: error: C compiler cannot create executables >>> See `config.log' for more details >>> ===> Script "configure" failed unexpectedly. >>> Please report the problem to x11@FreeBSD.org [maintainer] and attach the >>> "/usr/ports/graphics/dri/work/Mesa-9.1.7/config.log" including the output of >>> the failure of your make command. Also, it might be a good idea to provide >>> an overview of all packages installed on your system (e.g. a >>> /usr/local/sbin/pkg-static info -g -Ea). >>> *** [do-configure] Error code 1 >>> >>> Any thoughts on how to overcome this issue? >>> >>> Relevant info: >>> >>> # svn info /usr/src >>> >>> Path: /usr/src >>> Working Copy Root Path: /usr/src >>> URL: svn://svn.freebsd.org/base/stable/9 >>> Relative URL: ^/stable/9 >>> Repository Root: svn://svn.freebsd.org/base >>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>> Revision: 272203 >>> Node Kind: directory >>> Schedule: normal >>> Last Changed Author: thomas >>> Last Changed Rev: 272184 >>> Last Changed Date: 2014-09-26 12:13:13 -0700 (Fri, 26 Sep 2014) >>> >>> svn info /usr/ports >>> Path: /usr/ports >>> Working Copy Root Path: /usr/ports >>> URL: svn://svn.freebsd.org/ports/head >>> Relative URL: ^/head >>> Repository Root: svn://svn.freebsd.org/ports >>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >>> Revision: 369380 >>> Node Kind: directory >>> Schedule: normal >>> Last Changed Author: mva >>> Last Changed Rev: 369380 >>> Last Changed Date: 2014-09-27 01:34:11 -0700 (Sat, 27 Sep 2014) >>> >>> FreeBSD demon 9.3-STABLE FreeBSD 9.3-STABLE #0 r272203: Sat Sep 27 15:49:55 PDT 2014 >>> root@demon:/usr/obj/usr/src/sys/DEMON amd64 >>> >>> Thank you for all your time, and consideration. >>> >>> --Chris >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >> >> What does config.log say? > Please see attached (config.log.txt) -- it's big. :) > >> >> also 'clang -v' > nadda -- don't think it's installed -- WITHOUT_CLANG=true (/etc/make.conf) > > Thank you for your thoughtful reply, Allan. > > --Chris > >> >> >> -- >> Allan Jude >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" echo $CC It seems it is trying to use clang, and you have disabled clang check your /etc/make.conf you might need to add CC=gcc to /etc/make.conf to make it work Warning: I have no idea what I am talking about, it is 2am at a BSD conference hacking lounge -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 00:15:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F4BE8FD for ; Mon, 29 Sep 2014 00:15:28 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 228E8B66 for ; Mon, 29 Sep 2014 00:15:27 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8T0FUsv055396; Mon, 29 Sep 2014 00:15:30 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: "Mike." , freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Date: Mon, 29 Sep 2014 02:15:25 +0200 Message-Id: <20140928234329.M15139@beckpeccoz.com> In-Reply-To: <201409281153050191.00909A0F@smtp.24cl.home> References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 213.37.0.220 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 00:15:28 -0000 Hi Mike, it looks like we are hitting the same problem. If we find a third person with the same issue we can fund a club. :) Interesting to note: 1) we both run FBSD on small netbooks which usually get equipped with crappy ^D^D^D^D^D^D^D cheap hardware. 2) yours seems to be an Intel-only box, mine is an AMD-only, so the problem is not there (I mean, it's not the graphic chip). 3) we both have an Atheros wifi, whose driver has been updated recently, maybe this is the issue? As of now I suspect the problem is not related to AHCI because if you remove it from the kernel you still end up in an enless loop in some other driver. Actually the latest device_attach loops forever. You might still get some output from previous device probes complaining, notably USB, especially if you plug something in, or AHCI --as we both report--. I would like to debug the running kernel from another machine, altought the suggestions I got so far (see thread about kernel debugging in this same mailing list) are not encouraging. I will keep you posted, in the meantime you can try and boot your pc from 271146, it works for me. BR, On Sun, 28 Sep 2014 11:53:05 -0400, Mike. wrote > I'm starting to look at FreeBSD 11-current to see what's coming soon. > I have an older notebook that I use for test environments for > purposes such as this. Unfortunately, the notebook won't boot up > from the install CD, there's a loop it cannot seem to get out of. > > Details are: > > - The install CD was made from this image: > FreeBSD-11.0-CURRENT-i386-20140918-r271779-disc1 > > - The dmesg for the notebook is at the end of this message. The > dmesg was captured with FreeBSD 10.0. In the dmesg, you can see the > following lines: > > (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 > 00 00 00 > (aprobe0:ata1:0:1:0): CAM status: Command timeout > (aprobe0:ata1:0:1:0): Error 5, Retry was blocked > run_interrupt_driven_hooks: still waiting after 60 seconds for > xpt_config > (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 > 00 00 00 > (aprobe0:ata1:0:1:0): CAM status: Command timeout > (aprobe0:ata1:0:1:0): Error 5, Retry was blocked > > which, while slowing down the boot process drastically, still allowed > the boot process to run to successful completion. > > - When I try to boot using the FreeBSD 11-current install CD, that > loop seems to go on ad infinitum, or at least for the 5 minutes until > I gave up. I cannot post a dmesg from that boot-up because I never > got to a prompt. However, I did take a couple of pictures of the > offending screens. They are here: > http://archive.mgm51.com/cache/fbsd-11-current-01.jpg > http://archive.mgm51.com/cache/fbsd-11-current-02.jpg > The first image shows the start of the looping, and the second shows > the continuation. > > While this notebook is used only for testing, it is important to me > in that aspect. How can I get around this looping issue? > > Please let me know if there's any additional info you need. > > Thanks. > > And now, the dmesg... > > Copyright (c) 1992-2014 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 10.0-RELEASE-p8 #1 r271323: Wed Sep 10 20:25:45 EDT 2014 > root@a31pf.245l.home:/usr/obj/usr/src/sys/GENERIC i386 > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.60-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0xf24 Family = 0xf Model = 0x2 > Stepping = 4 > Features=0x3febf9ff PGE, MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT, > TM> real memory = 1073741824 (1024 MB) avail memory = 1029230592 > (981 MB) kbd1 at kbdmux0 random: initialized > acpi0: on motherboard acpi_ec0: GPE 0x1c, ECDT> port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of > 100000, 3ff00000 (3) failed cpu0: on acpi0 attimer0: timer> port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency > 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz > quality 100 atrtc0: port 0x70-0x71 irq 8 on > acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounter > "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit > timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: > on acpi0 acpi_button0: on > acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: > on pcib0 agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x3000-0x30ff mem > 0xe8000000-0xefffffff,0xd0100000-0xd010ffff irq 11 at device 0.0 on > pci1 > vgapci0: Boot video device > uhci0: port > 0x1800-0x181f irq 11 at device 29.0 on pci0 > usbus0 on uhci0 > uhci1: port > 0x1820-0x183f irq 11 at device 29.1 on pci0 > usbus1 on uhci1 > uhci2: port > 0x1840-0x185f irq 11 at device 29.2 on pci0 > usbus2 on uhci2 > pcib2: at device 30.0 on pci0 > pci2: on pcib2 > cbb0: mem 0x50000000-0x50000fff irq 11 > at device 0.0 on pci2 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb1: mem 0x50100000-0x50100fff irq 11 > at device 0.1 on pci2 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > pci2: at device 0.2 (no driver attached) > fxp0: port 0x8000-0x803f > mem 0xd0200000-0xd0200fff irq 11 at device 8.0 on pci2 > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, > auto-flow > fxp0: Ethernet address: 00:0e:9b:2c:d3:f6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on > pci0 > ata0: at channel 0 on atapci0 > ata1: at channel 1 on atapci0 > pci0: at device 31.3 (no driver attached) > pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff irq 11 > at device 31.5 on pci0 > pcm0: > pci0: at device 31.6 (no driver > attached) > acpi_tz0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > battery0: on acpi0 > acpi_acad0: on acpi0 > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff, > 0xe000 0-0xeffff pnpid ORM0000 on isa0 sc0: at > flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 ppc0: parallel port not found. acpi_perf0: Control> on cpu0 p4tcc0: on cpu0 > Timecounters tick every 1.000 msec random: unblocking device. > usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB > v1.0 usbus2: 12Mbps Full Speed USB v1.0 ugen2.1: at usbus2 > uhub0: on usbus2 > ugen1.1: at usbus1 > uhub1: on > usbus1 > ugen0.1: at usbus0 > uhub2: on > usbus0 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > ath0: irq 11 at device 0.0 on cardbus1 > ath0: AR5212 mac 5.6 RF5112 phy 4.1 > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0036 > (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 > 00 00 00 > (aprobe0:ata1:0:1:0): CAM status: Command timeout > (aprobe0:ata1:0:1:0): Error 5, Retry was blocked > run_interrupt_driven_hooks: still waiting after 60 seconds for > xpt_config > (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 > 00 00 00 > (aprobe0:ata1:0:1:0): CAM status: Command timeout > (aprobe0:ata1:0:1:0): Error 5, Retry was blocked > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-6 device > ada0: Serial Number MPC412Y4G6J1AE > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad0 > cd0 at ata1 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: Attempt to query device size failed: NOT READY, Medium not > present - tray closed > Trying to mount root from ufs:/dev/ada0p2 [rw]... > wlan0: Ethernet address: 00:04:e2:b6:d4:d6 > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 00:29:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC651B0D; Mon, 29 Sep 2014 00:29:43 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76B3BC4B; Mon, 29 Sep 2014 00:29:43 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8T0TvlC098697; Sun, 28 Sep 2014 17:30:03 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8T0TqH8098691; Sun, 28 Sep 2014 17:29:52 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sun, 28 Sep 2014 17:29:52 -0700 (PDT) Message-ID: <55ea1654e68d865f7becfa4bf57474c3.authenticated@ultimatedns.net> In-Reply-To: <54288C32.3080201@freebsd.org> References: <7b0a119ebc4d8d7813f92c0f94aba8d8.authenticated@ultimatedns.net> <542882B7.4060407@freebsd.org> <82259777bbe474bb5581c2b4a0b79f25.authenticated@ultimatedns.net> <54288C32.3080201@freebsd.org> Date: Sun, 28 Sep 2014 17:29:52 -0700 (PDT) Subject: Re: Mesa-9: configure: error: C compiler cannot create executables From: "Chris H" To: "Allan Jude" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 00:29:43 -0000 > On 09/28/2014 18:11, Chris H wrote: >>> On 09/28/2014 17:37, Chris H wrote: >>>> Greetings, >>>> A recent install of RELENG_9, followed by a build|install world|kernel. >>>> Returns the following error when attempting an make install of >>>> x11/xorg-minimal >>>> >>>> ===> Configuring for dri-9.1.7_5,2 >>>> configure: loading site script /usr/ports/Templates/config.site >>>> checking build system type... amd64-portbld-freebsd9.3 >>>> checking host system type... amd64-portbld-freebsd9.3 >>>> checking target system type... amd64-portbld-freebsd9.3 >>>> checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel >>>> checking whether build environment is sane... yes >>>> checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p >>>> checking for gawk... (cached) /usr/bin/awk >>>> checking whether gmake sets $(MAKE)... yes >>>> checking whether gmake supports nested variables... yes >>>> checking for style of include used by gmake... GNU >>>> checking for gcc... clang >>>> checking whether the C compiler works... no >>>> configure: error: in `/usr/ports/graphics/dri/work/Mesa-9.1.7': >>>> configure: error: C compiler cannot create executables >>>> See `config.log' for more details >>>> ===> Script "configure" failed unexpectedly. >>>> Please report the problem to x11@FreeBSD.org [maintainer] and attach the >>>> "/usr/ports/graphics/dri/work/Mesa-9.1.7/config.log" including the output of >>>> the failure of your make command. Also, it might be a good idea to provide >>>> an overview of all packages installed on your system (e.g. a >>>> /usr/local/sbin/pkg-static info -g -Ea). >>>> *** [do-configure] Error code 1 >>>> >>>> Any thoughts on how to overcome this issue? >>>> >>>> Relevant info: >>>> >>>> # svn info /usr/src >>>> >>>> Path: /usr/src >>>> Working Copy Root Path: /usr/src >>>> URL: svn://svn.freebsd.org/base/stable/9 >>>> Relative URL: ^/stable/9 >>>> Repository Root: svn://svn.freebsd.org/base >>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>> Revision: 272203 >>>> Node Kind: directory >>>> Schedule: normal >>>> Last Changed Author: thomas >>>> Last Changed Rev: 272184 >>>> Last Changed Date: 2014-09-26 12:13:13 -0700 (Fri, 26 Sep 2014) >>>> >>>> svn info /usr/ports >>>> Path: /usr/ports >>>> Working Copy Root Path: /usr/ports >>>> URL: svn://svn.freebsd.org/ports/head >>>> Relative URL: ^/head >>>> Repository Root: svn://svn.freebsd.org/ports >>>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >>>> Revision: 369380 >>>> Node Kind: directory >>>> Schedule: normal >>>> Last Changed Author: mva >>>> Last Changed Rev: 369380 >>>> Last Changed Date: 2014-09-27 01:34:11 -0700 (Sat, 27 Sep 2014) >>>> >>>> FreeBSD demon 9.3-STABLE FreeBSD 9.3-STABLE #0 r272203: Sat Sep 27 15:49:55 PDT 2014 >>>> root@demon:/usr/obj/usr/src/sys/DEMON amd64 >>>> >>>> Thank you for all your time, and consideration. >>>> >>>> --Chris >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>> >>> >>> What does config.log say? >> Please see attached (config.log.txt) -- it's big. :) >> >>> >>> also 'clang -v' >> nadda -- don't think it's installed -- WITHOUT_CLANG=true (/etc/make.conf) >> >> Thank you for your thoughtful reply, Allan. >> >> --Chris >> >>> >>> >>> -- >>> Allan Jude >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >>> >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > echo $CC # echo $CC CC: Undefined variable > > It seems it is trying to use clang, and you have disabled clang > > check your /etc/make.conf I'm carrying over defines from a 9.2-STABLE box: WITHOUT_CLANG=true FAVORITE_COMPILER=gcc These worked famously on the 9.2. So I thought them safe here (9.3). > > you might need to add CC=gcc to /etc/make.conf to make it work > > Warning: I have no idea what I am talking about, it is 2am at a BSD > conference hacking lounge LOL I wish you the best! :) Thank you for taking the time to reply, Allan. Especially under the circumstances! --Chris > > > -- > Allan Jude > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 00:31:27 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B8AAC1C for ; Mon, 29 Sep 2014 00:31:27 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 525C4CE6 for ; Mon, 29 Sep 2014 00:31:26 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8T0VVck055745; Mon, 29 Sep 2014 00:31:31 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: Garrett Cooper Subject: Re: What do you use for kernel debugging? Date: Mon, 29 Sep 2014 02:31:25 +0200 Message-Id: <20140929002025.M8991@aoek.com> In-Reply-To: <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> References: <20140928071641.M7664@beckpeccoz.com> <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 213.37.0.220 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 00:31:27 -0000 Hi Garrett, On Sun, 28 Sep 2014 13:38:24 -0700, Garrett Cooper wrote > On Sep 28, 2014, at 0:34, José Pérez Arauzo wrote: > > > Hello, > > I am trying to track down a (deadlock?) issue in CURRENT via DDB. The kernel does > > not complete hw probes on my Acer V5. > > > > I get stuck on apic_isr looping which leads nowhere. > > > > So I thought maybe things improve if I debug from another machine. > > > > > > What do you use for kernel debugging? According to the handbook kgdb over serial > > is a good option, do you agree? I'm on a netbook with no ethernet and no option > > for firewire: can I have a USB / nullmodem setup to work? > > > > I have no old-style uarts hardware anymore, as the handbook suggests... > > > > Any idea is welcome before I buy extra hw. I have a USB to serial showing up as > > /dev/cuaU0, do I need to grab another one and a nullmodem cable or there are better > > alternatives? Thank you. > > There was some discussion recently about this on an internal list. > Unfortunately no, there isn’t a usable way, but there were some > interesting viable methods that came up (which haven’t been > implemented): ethernet/sound/xHCI. > > Your best bet, as others have noted, is to use boot -d, use WITNESS > to spot locking issues, dtrace to isolate which section of code > there are problems, and finally use one of the DEBUG options noted > in /sys/conf/NOTES and /sys//conf/NOTES . > > Hope that helps! Well, it's not so encouraging but I'll work on it. Do you mean that we can get rid of chapter 10.5 of the handbook (On-Line Kernel Debugging Using Remote GDB)? Just to have it clear, when people develop or fix drivers in FreeBSD their only option is to use the above mentioned tools, as they have no access to a live, on-line kernel debugger?? It's disappointing, to say the least! I hope Dcons + 1394 works where it's applicable. BR, -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 00:35:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32CE1E75 for ; Mon, 29 Sep 2014 00:35:48 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3CF7D01 for ; Mon, 29 Sep 2014 00:35:47 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id j107so2547776qga.16 for ; Sun, 28 Sep 2014 17:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=a9LLzDINJGR3huLnjwOfAB9im/9pEZaj5Y2QZX5gM9Y=; b=BIqfVxv5fj06XHPLleA2WBdvQE8CArmTk9nrSWz65CWCFfvwyBregAaPPnEWB77/Sw /TxuLxUVp1uvmb7noG0fyQYwbHdZyaRhBVhtSriRtAwhTEC+Jl5NolbpUgvzEf00rLIi Tg/elnOf8JhaZJeKbHEP86bpJcyyQv5JuTz3ixgpsKCuTxRH+i2vAXo9pzpIDSw+TPjX E+ce9kQsdN3PqmT+/P1lHpYkahj/TaeqVGY3mVzY+RR0HAUuVbTobphe2zAUvpiJ0Ygt gVe42zRA4oJo4RKg92l2q7MbpiYf1vQc+vSUNFCE0NbtuqZj3ay9rc3A2RfIJA88Zj6L Cfmg== X-Received: by 10.229.62.129 with SMTP id x1mr46067388qch.16.1411950947071; Sun, 28 Sep 2014 17:35:47 -0700 (PDT) Received: from zhabar.attlocal.net (107-222-186-3.lightspeed.sntcca.sbcglobal.net. [107.222.186.3]) by mx.google.com with ESMTPSA id d60sm2478463qgd.35.2014.09.28.17.35.45 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Sep 2014 17:35:46 -0700 (PDT) Date: Sun, 28 Sep 2014 17:35:41 -0700 From: Justin Hibbits To: "=?ISO-8859-1?Q?Jos=E9_P=E9rez?= Arauzo" Subject: Re: What do you use for kernel debugging? Message-ID: <20140928173541.7939255a@zhabar.attlocal.net> In-Reply-To: <20140929002025.M8991@aoek.com> References: <20140928071641.M7664@beckpeccoz.com> <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> <20140929002025.M8991@aoek.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; powerpc64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 00:35:48 -0000 On Mon, 29 Sep 2014 02:31:25 +0200 "Jos=C3=A9 P=C3=A9rez Arauzo" wrote: > I hope Dcons + 1394 works where it's applicable. >=20 > BR, >=20 > -- > Jos=C3=A9 P=C3=A9rez Arauzo As a constant user of DCons+firewire, I can say it certainly works, and quite well at that. At least on PowerPC where firewire is everywhere. I only wish it were possible to use dcons+firewire even earlier in the boot (before the firewire device is probed), maybe initialize something in the loader. - Justin From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 00:51:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 565E2A1 for ; Mon, 29 Sep 2014 00:51:02 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CB12E6A for ; Mon, 29 Sep 2014 00:51:01 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8T0p6AE056201; Mon, 29 Sep 2014 00:51:06 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: Benjamin Kaduk Subject: Re: What do you use for kernel debugging? Date: Mon, 29 Sep 2014 02:51:01 +0200 Message-Id: <20140929003358.M78145@aoek.com> In-Reply-To: References: <20140928071641.M7664@beckpeccoz.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 213.37.0.220 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 00:51:02 -0000 Hi Benjamin, On Sun, 28 Sep 2014 15:54:36 -0400 (EDT), Benjamin Kaduk wrote > On Sun, 28 Sep 2014, José Pérez Arauzo wrote: > > > Hello, > > I am trying to track down a (deadlock?) issue in CURRENT via DDB. The kernel does > > not complete hw probes on my Acer V5. > > > > I get stuck on apic_isr looping which leads nowhere. > > > > So I thought maybe things improve if I debug from another machine. > > > > > > What do you use for kernel debugging? According to the handbook kgdb over serial > > is a good option, do you agree? I'm on a netbook with no ethernet and no option > > for firewire: can I have a USB / nullmodem setup to work? > > You cannot. Oh, what a shame. Why not? Is it because you need hardware probe to be over to use it? Today I bought a shining USB to USB thingy made by Hama, and guess what? It's not supported on FBDS, altought uplcom(4) reports support for Hama USB to RS232 brother. > > I have no old-style uarts hardware anymore, as the handbook suggests... > > > > Any idea is welcome before I buy extra hw. I have a USB to serial showing up as > > /dev/cuaU0, do I need to grab another one and a nullmodem cable or there are better > > alternatives? Thank you. > > I'm not sure that there are alternatives at all, unfortunately. > > You may be reduced to debugging-via-printf. Wow, bad news! :-| BR, -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 01:29:01 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3539B90F; Mon, 29 Sep 2014 01:29:01 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B7C761A0; Mon, 29 Sep 2014 01:29:00 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8T1TB8c010767; Sun, 28 Sep 2014 18:29:17 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8T1T6TQ010764; Sun, 28 Sep 2014 18:29:06 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sun, 28 Sep 2014 18:29:06 -0700 (PDT) Message-ID: <26670d7976dc83f6afaf63577f6c114d.authenticated@ultimatedns.net> In-Reply-To: <55ea1654e68d865f7becfa4bf57474c3.authenticated@ultimatedns.net> References: <7b0a119ebc4d8d7813f92c0f94aba8d8.authenticated@ultimatedns.net> <542882B7.4060407@freebsd.org> <82259777bbe474bb5581c2b4a0b79f25.authenticated@ultimatedns.net> <54288C32.3080201@freebsd.org> <55ea1654e68d865f7becfa4bf57474c3.authenticated@ultimatedns.net> Date: Sun, 28 Sep 2014 18:29:06 -0700 (PDT) Subject: Re: Mesa-9: configure: error: C compiler cannot create executables From: "Chris H" To: freebsd-stable@freebsd.org User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org, Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 01:29:01 -0000 >> On 09/28/2014 18:11, Chris H wrote: >>>> On 09/28/2014 17:37, Chris H wrote: >>>>> Greetings, >>>>> A recent install of RELENG_9, followed by a build|install world|kernel. >>>>> Returns the following error when attempting an make install of >>>>> x11/xorg-minimal >>>>> >>>>> ===> Configuring for dri-9.1.7_5,2 >>>>> configure: loading site script /usr/ports/Templates/config.site >>>>> checking build system type... amd64-portbld-freebsd9.3 >>>>> checking host system type... amd64-portbld-freebsd9.3 >>>>> checking target system type... amd64-portbld-freebsd9.3 >>>>> checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel >>>>> checking whether build environment is sane... yes >>>>> checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p >>>>> checking for gawk... (cached) /usr/bin/awk >>>>> checking whether gmake sets $(MAKE)... yes >>>>> checking whether gmake supports nested variables... yes >>>>> checking for style of include used by gmake... GNU >>>>> checking for gcc... clang >>>>> checking whether the C compiler works... no >>>>> configure: error: in `/usr/ports/graphics/dri/work/Mesa-9.1.7': >>>>> configure: error: C compiler cannot create executables >>>>> See `config.log' for more details >>>>> ===> Script "configure" failed unexpectedly. >>>>> Please report the problem to x11@FreeBSD.org [maintainer] and attach the >>>>> "/usr/ports/graphics/dri/work/Mesa-9.1.7/config.log" including the output of >>>>> the failure of your make command. Also, it might be a good idea to provide >>>>> an overview of all packages installed on your system (e.g. a >>>>> /usr/local/sbin/pkg-static info -g -Ea). >>>>> *** [do-configure] Error code 1 >>>>> >>>>> Any thoughts on how to overcome this issue? >>>>> >>>>> Relevant info: >>>>> >>>>> # svn info /usr/src >>>>> >>>>> Path: /usr/src >>>>> Working Copy Root Path: /usr/src >>>>> URL: svn://svn.freebsd.org/base/stable/9 >>>>> Relative URL: ^/stable/9 >>>>> Repository Root: svn://svn.freebsd.org/base >>>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>>> Revision: 272203 >>>>> Node Kind: directory >>>>> Schedule: normal >>>>> Last Changed Author: thomas >>>>> Last Changed Rev: 272184 >>>>> Last Changed Date: 2014-09-26 12:13:13 -0700 (Fri, 26 Sep 2014) >>>>> >>>>> svn info /usr/ports >>>>> Path: /usr/ports >>>>> Working Copy Root Path: /usr/ports >>>>> URL: svn://svn.freebsd.org/ports/head >>>>> Relative URL: ^/head >>>>> Repository Root: svn://svn.freebsd.org/ports >>>>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >>>>> Revision: 369380 >>>>> Node Kind: directory >>>>> Schedule: normal >>>>> Last Changed Author: mva >>>>> Last Changed Rev: 369380 >>>>> Last Changed Date: 2014-09-27 01:34:11 -0700 (Sat, 27 Sep 2014) >>>>> >>>>> FreeBSD demon 9.3-STABLE FreeBSD 9.3-STABLE #0 r272203: Sat Sep 27 15:49:55 PDT 2014 >>>>> root@demon:/usr/obj/usr/src/sys/DEMON amd64 >>>>> >>>>> Thank you for all your time, and consideration. >>>>> >>>>> --Chris >>>>> >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>>> >>>> >>>> What does config.log say? >>> Please see attached (config.log.txt) -- it's big. :) >>> >>>> >>>> also 'clang -v' >>> nadda -- don't think it's installed -- WITHOUT_CLANG=true (/etc/make.conf) >>> >>> Thank you for your thoughtful reply, Allan. >>> >>> --Chris >>> >>>> >>>> >>>> -- >>>> Allan Jude >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>> >>>> >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> echo $CC > # echo $CC > CC: Undefined variable >> >> It seems it is trying to use clang, and you have disabled clang >> >> check your /etc/make.conf > I'm carrying over defines from a 9.2-STABLE box: > WITHOUT_CLANG=true > FAVORITE_COMPILER=gcc > > These worked famously on the 9.2. So I thought them safe here (9.3). >> >> you might need to add CC=gcc to /etc/make.conf to make it work >> >> Warning: I have no idea what I am talking about, it is 2am at a BSD >> conference hacking lounge > LOL I wish you the best! :) > > Thank you for taking the time to reply, Allan. Especially under the > circumstances! > > --Chris A trip to lang/gcc; make install clean. Also failed to help. I guess there isn't a compiler capable of creating executables available with RELENG_9? Is this some fascist move to eliminate (g)cc from FreeBSD. So that only clang/llvm work? ugh. :-| --Chris >> >> >> -- >> Allan Jude >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 01:31:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE442B2F for ; Mon, 29 Sep 2014 01:31:45 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91D3B266 for ; Mon, 29 Sep 2014 01:31:45 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id bj1so9515973pad.21 for ; Sun, 28 Sep 2014 18:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=6ihqH1KOlmIEcKFglDTqHEliin8tKDZZt/V6FCtQPVA=; b=xRt4SBjyexffFrWyr1T5XSJVuVq0XgzoXSzIigeChf+edJTKoZ+yZBzrKrLUnEQGlR rmL74W2OxIOm0uJHz83g4Wp4tvyyDyRR2KPlujxmiB0ODq8Ozdm8jTHTQXJxsfrljnmq wyxVZqy47jycYrE/CCBJEu2FIb04nv/OLrKb0oqKuA3gtSYk6NolHwIRfYBbafNSgis6 Lwyo6u18A4mYnWf78QtLzPeCEo8wkFaPaItAQ2REfPnZcIHEnxjgTGrZrVftXNrWAhIa 3t14Xp/pfazULG9BgKFZ6r9Lyabatu3ur9rqrtFrR0qjNb/7eaM8Eo7fL5SK5QJf9IE7 5qbw== X-Received: by 10.66.129.199 with SMTP id ny7mr14464665pab.16.1411954305029; Sun, 28 Sep 2014 18:31:45 -0700 (PDT) Received: from [10.69.49.218] (mobile-166-137-213-165.mycingular.net. [166.137.213.165]) by mx.google.com with ESMTPSA id iu10sm10698688pbd.57.2014.09.28.18.31.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Sep 2014 18:31:44 -0700 (PDT) References: <20140928071641.M7664@beckpeccoz.com> <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> <20140929002025.M8991@aoek.com> <20140928173541.7939255a@zhabar.attlocal.net> Mime-Version: 1.0 (1.0) In-Reply-To: <20140928173541.7939255a@zhabar.attlocal.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <7C966773-F0BF-4114-A20E-3BC26F70A860@gmail.com> X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: What do you use for kernel debugging? Date: Sun, 28 Sep 2014 18:31:39 -0700 To: Justin Hibbits Cc: =?utf-8?Q?Jos=C3=A9_P=C3=A9rez_Arauzo?= , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 01:31:45 -0000 > On Sep 28, 2014, at 17:35, Justin Hibbits wrote: >=20 > On Mon, 29 Sep 2014 02:31:25 +0200 > "Jos=C3=A9 P=C3=A9rez Arauzo" wrote: >=20 >> I hope Dcons + 1394 works where it's applicable. >>=20 >> BR, >>=20 >> -- >> Jos=C3=A9 P=C3=A9rez Arauzo >=20 > As a constant user of DCons+firewire, I can say it certainly works, and > quite well at that. At least on PowerPC where firewire is everywhere. > I only wish it were possible to use dcons+firewire even earlier in the > boot (before the firewire device is probed), maybe initialize something > in the loader. It would be nice if both the FireWire and USB subsystems started up sooner. T= here are other issues (with USB for instance), where ukbd not being initiali= zed before the mount root prompt can leave the system undebuggable. In the short term: can the SYSINIT priority be changed in the drivers to sup= port this? It would be nice if there was a pluggable infrastructure for bootloader enab= ling of devices as debugger consoles that would make this possible. Thanks! -Garrett= From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 01:35:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98A7CC62 for ; Mon, 29 Sep 2014 01:35:57 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C46227C for ; Mon, 29 Sep 2014 01:35:57 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id rd3so6972794pab.4 for ; Sun, 28 Sep 2014 18:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=gj3qL5/qiPz3wZpojvzDwH2S7HSji9pZ8bdOsObF8pg=; b=cPdfyCte1o1CByB5gjd8imBzy7j7XzjV7UeESYW7KRPGX7bUbpKM12D0mNYrbApYm+ okFtHVuvRYF6tC8hbA49xwlJzYvjACU2jVflA9FLlpInBC5CUmvH0JH9dtmEXP08ZrKW +pADV+ktPQcoAP+3dNcIRpLXmwDUFFjpYStsx5NNn2FxNMkbamy79eYfheodTSZtzqYv ZRn+JQV0Ju93oNKm06TGldTKli9EZlxNftT+InlZ1Q2kys00vvFWayRP46Db6PB1BxlL D/4LVaH8qTOgyyyOHepqWGEZGmnYF8NAXQIBOHpyl/aGe7R3bGS7cB6axaroUhQI3Ii/ fQYQ== X-Received: by 10.67.5.40 with SMTP id cj8mr54691210pad.137.1411954557063; Sun, 28 Sep 2014 18:35:57 -0700 (PDT) Received: from [10.69.49.218] (mobile-166-137-213-165.mycingular.net. [166.137.213.165]) by mx.google.com with ESMTPSA id uf6sm10818861pac.16.2014.09.28.18.35.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Sep 2014 18:35:56 -0700 (PDT) References: <20140928071641.M7664@beckpeccoz.com> <20140929003358.M78145@aoek.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20140929003358.M78145@aoek.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: What do you use for kernel debugging? Date: Sun, 28 Sep 2014 18:35:51 -0700 To: =?utf-8?Q?Jos=C3=A9_P=C3=A9rez_Arauzo?= Cc: FreeBSD Current , Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 01:35:57 -0000 > On Sep 28, 2014, at 17:51, "Jos=C3=A9 P=C3=A9rez Arauzo" wr= ote: >=20 > Hi Benjamin, >=20 > On Sun, 28 Sep 2014 15:54:36 -0400 (EDT), Benjamin Kaduk wrote >> On Sun, 28 Sep 2014, Jos=C3=A9 P=C3=A9rez Arauzo wrote: >>=20 >>> Hello, >>> I am trying to track down a (deadlock?) issue in CURRENT via DDB. The > kernel does >>> not complete hw probes on my Acer V5. >>>=20 >>> I get stuck on apic_isr looping which leads nowhere. >>>=20 >>> So I thought maybe things improve if I debug from another machine. >>>=20 >>>=20 >>> What do you use for kernel debugging? According to the handbook kgdb ove= r > serial >>> is a good option, do you agree? I'm on a netbook with no ethernet and no= > option >>> for firewire: can I have a USB / nullmodem setup to work? >>=20 >> You cannot. >=20 > Oh, what a shame. Why not? Is it because you need hardware probe to > be over to use it? >=20 > Today I bought a shining USB to USB thingy made by Hama, and guess what? > It's not supported on FBDS, altought uplcom(4) reports support for > Hama USB to RS232 brother. The bootloader doesn't support USB debugging and I'm pretty sure the devices= don't support local/remote debugging :(.. I'll do some poking around. I'll t= alk to some SMEs and see if I can write up a TODO list for a wiki page. Cheers!= From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 01:43:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41A86DBC for ; Mon, 29 Sep 2014 01:43:51 +0000 (UTC) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15C9B35E for ; Mon, 29 Sep 2014 01:43:51 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id fp1so3265187pdb.21 for ; Sun, 28 Sep 2014 18:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=vsfQlpOhda319LQo3sgn8fWtYyBwjIi2Abh1RzUOVAY=; b=a7T+OQ7x0985zSYM+TNUeYOR0CaPd80WlBWHbjmwnMCsFidvKWz5BRZuszf7DF9NdA 9mwqaD37G9Z8A2WtgGtKccjQgt8w6rauZYiP0CV45Io+x74CWdi/1BKF9dAfTDGAol1b CEXouedsh9na5qOF94IaPs754BEBr8nTnp8rj3YBj3H3WV63kzrSLtC6Ot+NUwDgVdEm EMUttahe8HmDF+8lsNin0waeo9aRM7x4afTs1nFGH5sZx6Fxi4h4e4Cf2vzWFTqwgBKP ybvfHbMkolWFvYkYYrl4dQQ/koS2kc8GgFoAYNc/qb6P2dZNPt5ZRA7csMgm1bBk3fjZ gZmQ== X-Received: by 10.70.30.97 with SMTP id r1mr67595019pdh.109.1411955030663; Sun, 28 Sep 2014 18:43:50 -0700 (PDT) Received: from [10.69.49.218] (mobile-166-137-213-165.mycingular.net. [166.137.213.165]) by mx.google.com with ESMTPSA id ps1sm10813229pac.41.2014.09.28.18.43.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Sep 2014 18:43:49 -0700 (PDT) References: <20140928071641.M7664@beckpeccoz.com> <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> <20140929002025.M8991@aoek.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20140929002025.M8991@aoek.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <82981B04-42EF-4F06-A01D-5465D91C2B86@gmail.com> X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: What do you use for kernel debugging? Date: Sun, 28 Sep 2014 18:43:45 -0700 To: =?utf-8?Q?Jos=C3=A9_P=C3=A9rez_Arauzo?= Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 01:43:51 -0000 > On Sep 28, 2014, at 17:31, "Jos=C3=A9 P=C3=A9rez Arauzo" wr= ote: >=20 > Hi Garrett, >=20 > On Sun, 28 Sep 2014 13:38:24 -0700, Garrett Cooper wrote >> On Sep 28, 2014, at 0:34, Jos=C3=A9 P=C3=A9rez Arauzo wrot= e: >>=20 >>> Hello, >>> I am trying to track down a (deadlock?) issue in CURRENT via DDB. The > kernel does >>> not complete hw probes on my Acer V5. >>>=20 >>> I get stuck on apic_isr looping which leads nowhere. >>>=20 >>> So I thought maybe things improve if I debug from another machine. >>>=20 >>>=20 >>> What do you use for kernel debugging? According to the handbook kgdb ove= r > serial >>> is a good option, do you agree? I'm on a netbook with no ethernet and no= > option >>> for firewire: can I have a USB / nullmodem setup to work? >>>=20 >>> I have no old-style uarts hardware anymore, as the handbook suggests... >>>=20 >>> Any idea is welcome before I buy extra hw. I have a USB to serial showin= g > up as >>> /dev/cuaU0, do I need to grab another one and a nullmodem cable or there= > are better >>> alternatives? Thank you. >>=20 >> There was some discussion recently about this on an internal list.=20 >> Unfortunately no, there isn=E2=80=99t a usable way, but there were some=20= >> interesting viable methods that came up (which haven=E2=80=99t been=20 >> implemented): ethernet/sound/xHCI. >>=20 >> Your best bet, as others have noted, is to use boot -d, use WITNESS=20 >> to spot locking issues, dtrace to isolate which section of code=20 >> there are problems, and finally use one of the DEBUG options noted=20 >> in /sys/conf/NOTES and /sys//conf/NOTES . >>=20 >> Hope that helps! >=20 > Well, it's not so encouraging but I'll work on it. >=20 > Do you mean that we can get rid of chapter 10.5 of the handbook (On-Line > Kernel Debugging Using Remote GDB)? No. It still works quite well with serial consoles (both physical and virtua= l uarts, i.e. IPMI). > Just to have it clear, when people develop or fix drivers in FreeBSD > their only option is to use the above mentioned tools, as they have no > access to a live, on-line kernel debugger?? It's disappointing, to say > the least! There are other things that people use, but they're a bit expensive. I'll ha= ve to look up =20 > I hope Dcons + 1394 works where it's applicable. Yes, it should work as a debug console if the system has been booted up. When I was debugging getting ACPI to work on my netbook, here were some othe= r things I did to get the system up and going: - Built a stripped down kernel that just contains the essential bits (CPU, f= ilesystem, storage). - built one kernel with debug bits and one with release bits (titled them di= fferently of course). - built networking and other components as klds and loaded them at boot. This gave me a quick turnaround time when figuring out what was broken suspe= nd/resume wise. It might help you isolate which drivers or subsystems are ca= using boot issues as well (at least netbook system boot is relatively quick c= ompared to the other systems I boot off of with gobs of ram and storage driv= es...). HTH! -Garrett= From owner-freebsd-current@FreeBSD.ORG Sun Sep 28 23:53:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC381666; Sun, 28 Sep 2014 23:53:06 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92B4998A; Sun, 28 Sep 2014 23:53:06 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8SNrJ8h092681; Sun, 28 Sep 2014 16:53:25 -0700 (PDT) (envelope-from chrish@UltimateDNS.NET) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8SNrEAT092675; Sun, 28 Sep 2014 16:53:14 -0700 (PDT) (envelope-from chrish@UltimateDNS.NET) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sun, 28 Sep 2014 16:53:14 -0700 (PDT) Message-ID: <2f57a51d93ff57100318e537732cbf81.authenticated@ultimatedns.net> In-Reply-To: <54288C32.3080201@freebsd.org> References: <7b0a119ebc4d8d7813f92c0f94aba8d8.authenticated@ultimatedns.net> <542882B7.4060407@freebsd.org> <82259777bbe474bb5581c2b4a0b79f25.authenticated@ultimatedns.net> <54288C32.3080201@freebsd.org> Date: Sun, 28 Sep 2014 16:53:14 -0700 (PDT) Subject: Re: Mesa-9: configure: error: C compiler cannot create executables From: chrish@UltimateDNS.NET To: "Allan Jude" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 29 Sep 2014 02:08:29 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 23:53:07 -0000 > On 09/28/2014 18:11, Chris H wrote: >>> On 09/28/2014 17:37, Chris H wrote: >>>> Greetings, >>>> A recent install of RELENG_9, followed by a build|install world|kernel. >>>> Returns the following error when attempting an make install of >>>> x11/xorg-minimal >>>> >>>> ===> Configuring for dri-9.1.7_5,2 >>>> configure: loading site script /usr/ports/Templates/config.site >>>> checking build system type... amd64-portbld-freebsd9.3 >>>> checking host system type... amd64-portbld-freebsd9.3 >>>> checking target system type... amd64-portbld-freebsd9.3 >>>> checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel >>>> checking whether build environment is sane... yes >>>> checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p >>>> checking for gawk... (cached) /usr/bin/awk >>>> checking whether gmake sets $(MAKE)... yes >>>> checking whether gmake supports nested variables... yes >>>> checking for style of include used by gmake... GNU >>>> checking for gcc... clang >>>> checking whether the C compiler works... no >>>> configure: error: in `/usr/ports/graphics/dri/work/Mesa-9.1.7': >>>> configure: error: C compiler cannot create executables >>>> See `config.log' for more details >>>> ===> Script "configure" failed unexpectedly. >>>> Please report the problem to x11@FreeBSD.org [maintainer] and attach the >>>> "/usr/ports/graphics/dri/work/Mesa-9.1.7/config.log" including the output of >>>> the failure of your make command. Also, it might be a good idea to provide >>>> an overview of all packages installed on your system (e.g. a >>>> /usr/local/sbin/pkg-static info -g -Ea). >>>> *** [do-configure] Error code 1 >>>> >>>> Any thoughts on how to overcome this issue? >>>> >>>> Relevant info: >>>> >>>> # svn info /usr/src >>>> >>>> Path: /usr/src >>>> Working Copy Root Path: /usr/src >>>> URL: svn://svn.freebsd.org/base/stable/9 >>>> Relative URL: ^/stable/9 >>>> Repository Root: svn://svn.freebsd.org/base >>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>> Revision: 272203 >>>> Node Kind: directory >>>> Schedule: normal >>>> Last Changed Author: thomas >>>> Last Changed Rev: 272184 >>>> Last Changed Date: 2014-09-26 12:13:13 -0700 (Fri, 26 Sep 2014) >>>> >>>> svn info /usr/ports >>>> Path: /usr/ports >>>> Working Copy Root Path: /usr/ports >>>> URL: svn://svn.freebsd.org/ports/head >>>> Relative URL: ^/head >>>> Repository Root: svn://svn.freebsd.org/ports >>>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >>>> Revision: 369380 >>>> Node Kind: directory >>>> Schedule: normal >>>> Last Changed Author: mva >>>> Last Changed Rev: 369380 >>>> Last Changed Date: 2014-09-27 01:34:11 -0700 (Sat, 27 Sep 2014) >>>> >>>> FreeBSD demon 9.3-STABLE FreeBSD 9.3-STABLE #0 r272203: Sat Sep 27 15:49:55 PDT 2014 >>>> root@demon:/usr/obj/usr/src/sys/DEMON amd64 >>>> >>>> Thank you for all your time, and consideration. >>>> >>>> --Chris >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>> >>> >>> What does config.log say? >> Please see attached (config.log.txt) -- it's big. :) >> >>> >>> also 'clang -v' >> nadda -- don't think it's installed -- WITHOUT_CLANG=true (/etc/make.conf) >> >> Thank you for your thoughtful reply, Allan. >> >> --Chris >> >>> >>> >>> -- >>> Allan Jude >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >>> >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > echo $CC > > It seems it is trying to use clang, and you have disabled clang > > check your /etc/make.conf I'm carrying over defines from a 9.2-STABLE box: WITHOUT_CLANG=true FAVORITE_COMPILER=gcc These worked famously on the 9.2. So I thought them safe here (9.3). > > you might need to add CC=gcc to /etc/make.conf to make it work # echo $CC CC: Undefined variable > > Warning: I have no idea what I am talking about, it is 2am at a BSD > conference hacking lounge LOL I wish you the best! :) Thank you for taking the time to reply, Allan. Especially under the circumstances! --Chris > > > -- > Allan Jude > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 03:15:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6672E37; Mon, 29 Sep 2014 03:15:13 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 79C7FDDD; Mon, 29 Sep 2014 03:15:13 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8T3FSI4036735; Sun, 28 Sep 2014 20:15:33 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8T3FMqf036729; Sun, 28 Sep 2014 20:15:22 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Sun, 28 Sep 2014 20:15:23 -0700 (PDT) Message-ID: <411fc42685f5deb5ca9cf02374fc531a.authenticated@ultimatedns.net> In-Reply-To: <26670d7976dc83f6afaf63577f6c114d.authenticated@ultimatedns.net> References: <7b0a119ebc4d8d7813f92c0f94aba8d8.authenticated@ultimatedns.net> <542882B7.4060407@freebsd.org> <82259777bbe474bb5581c2b4a0b79f25.authenticated@ultimatedns.net> <54288C32.3080201@freebsd.org> <55ea1654e68d865f7becfa4bf57474c3.authenticated@ultimatedns.net> <26670d7976dc83f6afaf63577f6c114d.authenticated@ultimatedns.net> Date: Sun, 28 Sep 2014 20:15:23 -0700 (PDT) Subject: Re: Mesa-9: configure: error: C compiler cannot create executables From: "Chris H" To: "Allan Jude" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 03:15:14 -0000 >>> On 09/28/2014 18:11, Chris H wrote: >>>>> On 09/28/2014 17:37, Chris H wrote: >>>>>> Greetings, >>>>>> A recent install of RELENG_9, followed by a build|install world|kernel. >>>>>> Returns the following error when attempting an make install of >>>>>> x11/xorg-minimal >>>>>> >>>>>> ===> Configuring for dri-9.1.7_5,2 >>>>>> configure: loading site script /usr/ports/Templates/config.site >>>>>> checking build system type... amd64-portbld-freebsd9.3 >>>>>> checking host system type... amd64-portbld-freebsd9.3 >>>>>> checking target system type... amd64-portbld-freebsd9.3 >>>>>> checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel >>>>>> checking whether build environment is sane... yes >>>>>> checking for a thread-safe mkdir -p... (cached) /bin/mkdir -p >>>>>> checking for gawk... (cached) /usr/bin/awk >>>>>> checking whether gmake sets $(MAKE)... yes >>>>>> checking whether gmake supports nested variables... yes >>>>>> checking for style of include used by gmake... GNU >>>>>> checking for gcc... clang >>>>>> checking whether the C compiler works... no >>>>>> configure: error: in `/usr/ports/graphics/dri/work/Mesa-9.1.7': >>>>>> configure: error: C compiler cannot create executables >>>>>> See `config.log' for more details >>>>>> ===> Script "configure" failed unexpectedly. >>>>>> Please report the problem to x11@FreeBSD.org [maintainer] and attach the >>>>>> "/usr/ports/graphics/dri/work/Mesa-9.1.7/config.log" including the output of >>>>>> the failure of your make command. Also, it might be a good idea to provide >>>>>> an overview of all packages installed on your system (e.g. a >>>>>> /usr/local/sbin/pkg-static info -g -Ea). >>>>>> *** [do-configure] Error code 1 >>>>>> >>>>>> Any thoughts on how to overcome this issue? >>>>>> >>>>>> Relevant info: >>>>>> >>>>>> # svn info /usr/src >>>>>> >>>>>> Path: /usr/src >>>>>> Working Copy Root Path: /usr/src >>>>>> URL: svn://svn.freebsd.org/base/stable/9 >>>>>> Relative URL: ^/stable/9 >>>>>> Repository Root: svn://svn.freebsd.org/base >>>>>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >>>>>> Revision: 272203 >>>>>> Node Kind: directory >>>>>> Schedule: normal >>>>>> Last Changed Author: thomas >>>>>> Last Changed Rev: 272184 >>>>>> Last Changed Date: 2014-09-26 12:13:13 -0700 (Fri, 26 Sep 2014) >>>>>> >>>>>> svn info /usr/ports >>>>>> Path: /usr/ports >>>>>> Working Copy Root Path: /usr/ports >>>>>> URL: svn://svn.freebsd.org/ports/head >>>>>> Relative URL: ^/head >>>>>> Repository Root: svn://svn.freebsd.org/ports >>>>>> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >>>>>> Revision: 369380 >>>>>> Node Kind: directory >>>>>> Schedule: normal >>>>>> Last Changed Author: mva >>>>>> Last Changed Rev: 369380 >>>>>> Last Changed Date: 2014-09-27 01:34:11 -0700 (Sat, 27 Sep 2014) >>>>>> >>>>>> FreeBSD demon 9.3-STABLE FreeBSD 9.3-STABLE #0 r272203: Sat Sep 27 15:49:55 PDT 2014 >>>>>> root@demon:/usr/obj/usr/src/sys/DEMON amd64 >>>>>> >>>>>> Thank you for all your time, and consideration. >>>>>> >>>>>> --Chris >>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-current@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>>>> >>>>> >>>>> What does config.log say? >>>> Please see attached (config.log.txt) -- it's big. :) >>>> >>>>> >>>>> also 'clang -v' >>>> nadda -- don't think it's installed -- WITHOUT_CLANG=true (/etc/make.conf) >>>> >>>> Thank you for your thoughtful reply, Allan. >>>> >>>> --Chris >>>> >>>>> >>>>> >>>>> -- >>>>> Allan Jude >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >>> echo $CC >> # echo $CC >> CC: Undefined variable >>> >>> It seems it is trying to use clang, and you have disabled clang >>> >>> check your /etc/make.conf >> I'm carrying over defines from a 9.2-STABLE box: >> WITHOUT_CLANG=true >> FAVORITE_COMPILER=gcc >> >> These worked famously on the 9.2. So I thought them safe here (9.3). >>> >>> you might need to add CC=gcc to /etc/make.conf to make it work >>> >>> Warning: I have no idea what I am talking about, it is 2am at a BSD >>> conference hacking lounge >> LOL I wish you the best! :) >> >> Thank you for taking the time to reply, Allan. Especially under the >> circumstances! >> >> --Chris > > A trip to lang/gcc; make install clean. Also failed to help. > I guess there isn't a compiler capable of creating executables > available with RELENG_9? Is this some fascist move to eliminate > (g)cc from FreeBSD. So that only clang/llvm work? > > ugh. :-| Well. A quick look at graphics/dri/Makefile, reveals it is a diabolical plot to insist gcc goes away. :( I simply commented the conditional, and added GCC to suit my needs. :) # gcc from base can't handle some code in mesa 9.1+ # We only care for 9.x and 8.x, not for old pre-clang default current. # This is for 0b0000 binary which gcc 4.3+ understands and is in the i965 driver. .if defined(WITH_NEW_XORG) . if (${OSVERSION} >= 901500 && ${OSVERSION} < 1000000) \ && ${ARCH} == amd64 USE_GCC=yes #CC=clang #CXX=clang++ #CPP=clang-cpp . elif ${OSVERSION} < 901500 USE_GCC=yes . endif .endif Die clang, die! --Chris > > > --Chris > >>> >>> >>> -- >>> Allan Jude >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 08:13:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3389E600 for ; Mon, 29 Sep 2014 08:13:50 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE3B91DE for ; Mon, 29 Sep 2014 08:13:49 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8T8DlDp067300; Mon, 29 Sep 2014 08:13:47 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: Garrett Cooper Subject: Re: What do you use for kernel debugging? Date: Mon, 29 Sep 2014 10:13:42 +0200 Message-Id: <20140929081149.M42132@aoek.com> In-Reply-To: <82981B04-42EF-4F06-A01D-5465D91C2B86@gmail.com> References: <20140928071641.M7664@beckpeccoz.com> <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> <20140929002025.M8991@aoek.com> <82981B04-42EF-4F06-A01D-5465D91C2B86@gmail.com> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 213.37.0.220 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 08:13:50 -0000 Hi Garrett, On Sun, 28 Sep 2014 18:43:45 -0700, Garrett Cooper wrote [...] > When I was debugging getting ACPI to work on my netbook, here were > some other things I did to get the system up and going: - Built a > stripped down kernel that just contains the essential bits (CPU, > filesystem, storage). - built one kernel with debug bits and one > with release bits (titled them differently of course). - built > networking and other components as klds and loaded them at boot. > This gave me a quick turnaround time when figuring out what was > broken suspend/resume wise. It might help you isolate which drivers > or subsystems are causing boot issues as well (at least netbook > system boot is relatively quick compared to the other systems I boot > off of with gobs of ram and storage drives...). > > HTH! > -Garrett Yes, that's gold. It might not apply to the specific case where device probe does not complete, but I'll give it a try. Give me a day or two. Thank you! BR, -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 11:48:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 61580BAA for ; Mon, 29 Sep 2014 11:48:19 +0000 (UTC) Received: from mail.auburn.protected-networks.net (mail.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.auburn.protected-networks.net", Issuer "Protected Networks Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 27012C76 for ; Mon, 29 Sep 2014 11:48:19 +0000 (UTC) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Iain Butler", Issuer "RSA Class 2 Personal CA v2" (verified OK)) (Authenticated sender: imb@mail.auburn.protected-networks.net) by mail.auburn.protected-networks.net (Postfix) with ESMTPSA id 73B36B838 for ; Mon, 29 Sep 2014 07:48:16 -0400 (EDT) Message-ID: <542946FA.2080700@protected-networks.net> Date: Mon, 29 Sep 2014 07:48:10 -0400 From: Michael Butler User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-current Subject: SVN r272273 breaks 'dump' OpenPGP: id=0442D492 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0VRUPeCFdcKIeHfH9HRt6ItWvFpTswhnN" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 11:48:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0VRUPeCFdcKIeHfH9HRt6ItWvFpTswhnN Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It seems that the strptime changes broke the recognition of /etc/dumpdates. Last night's level 2 dump turned into a level 0: DUMP: Date of this level 2 dump: Mon Sep 29 00:10:26 2014 DUMP: Unknown intermediate format in /etc/dumpdates, line 1 DUMP: Unknown intermediate format in /etc/dumpdates, line 1 DUMP: Unknown intermediate format in /etc/dumpdates, line 1 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/ada0s3a (/) to standard output DUMP: mapping (Pass I) [regular files] imb --0VRUPeCFdcKIeHfH9HRt6ItWvFpTswhnN 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 iEYEARECAAYFAlQpRv8ACgkQQv9rrgRC1JJVoQCfRiwR/TZq1x5eUODYacmso7/t XzQAoJDEpLIzPR7SMVeCZCWkZTnxFtof =CFbU -----END PGP SIGNATURE----- --0VRUPeCFdcKIeHfH9HRt6ItWvFpTswhnN-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 14:13:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26C3DF06 for ; Mon, 29 Sep 2014 14:13:46 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E76FEFAA for ; Mon, 29 Sep 2014 14:13:45 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j65Lc2wG0z1DNt for ; Mon, 29 Sep 2014 10:13:44 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j65LZ5LQwz1Bwg for ; Mon, 29 Sep 2014 10:13:42 -0400 (EDT) Message-ID: <201409291013410138.00509BD3@smtp.24cl.home> In-Reply-To: <20140928234329.M15139@beckpeccoz.com> References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <20140928234329.M15139@beckpeccoz.com> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Mon, 29 Sep 2014 10:13:41 -0400 From: "Mike." To: freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 14:13:46 -0000 On 9/29/2014 at 2:15 AM Jos=C3=A9 P=C3=A9rez Arauzo wrote: |This encoded message has been converted to an attachment. | |Hi Mike, |It looks like we are hitting the same problem. If we find a |third person with the same issue we can fund a club. :) |Interesting to note: | 1) we both run FBSD on small netbooks which usually get | equipped with crappy ^D^D^D^D^D^D^D cheap hardware. | 2) yours seems to be an Intel-only box, mine is an AMD-only, | so the problem is not there (I mean, it's not the graphic | chip). | 3) we both have an Atheros wifi, whose driver has been updated | recently, maybe this is the issue? The notebook in question is a circa-2002 IBM Thinkpad A31p (of the "workstation replacement" genre of the day). If you're curious, here's more info on it: http://www.tomsguide.com/us/ibm-thinkpad-a31p,review-42.html The Atheros WiFi is a SMC PC-Card adapter. I can unplug it to see if it has any effect on the issue. I'll do that later today when the compiling finishes. :) [snip] |I will keep you posted, in the meantime you can try and | boot your pc from 271146, it works for me. Once I figure out how to do that, I'll give it a try. :) Meanwhile, make buildkernel with 270327 should finish compiling in a few hours.... Thanks. Mike. From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 14:31:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFAB9955; Mon, 29 Sep 2014 14:31:13 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9CA971A6; Mon, 29 Sep 2014 14:31:13 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8TEVTVc010237; Mon, 29 Sep 2014 07:31:35 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8TEVMgr010213; Mon, 29 Sep 2014 07:31:22 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 29 Sep 2014 07:31:24 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Mon, 29 Sep 2014 07:31:24 -0700 (PDT) Subject: Re: dmesg seems broken From: "Chris H" To: "Brandon Allbery" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd current , freebsd stable , freebsd amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 14:31:13 -0000 > On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote: > >> Where can I get that information? Where was it sent? Why am I >> not allowed to view it? >> > > Sounds to me like the kernel ring buffer is now too small for all the early > boot messages? OK more investigation indicates that bumping kern.msgbufsize will return the missing bits. Maybe this is what you were trying to tell me. ;) Anyway. Anyone know why was this tunable reduced? I don't experience this on RELENG_8, or 11-CURRENT. FWIW I have loader.conf(5) set to boot verbose. But still didn't get the info expected. :( Thanks for the reply, Brandon. --Chris > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b@gmail.com ballbery@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 15:25:44 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76DCCD8F for ; Mon, 29 Sep 2014 15:25:44 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3C24EA83 for ; Mon, 29 Sep 2014 15:25:43 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 16AE47302B; Mon, 29 Sep 2014 17:30:43 +0200 (CEST) Date: Mon, 29 Sep 2014 17:30:43 +0200 From: Luigi Rizzo To: current@freebsd.org Subject: capsicum and netmap ? Message-ID: <20140929153043.GA78397@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 15:25:44 -0000 Hi, while trying the netmap-enabled libpcap library with tcpdump, i noticed it fails to return data on a kernel with capsicum (the string "capability mode sandbox enabled" made me suspicious, and removing the cap_*() calls from tcpdump.c seems to make things work again). Would anyone be able to point me what should be done in the netmap kernel module to make it work with capsicum ? I am sure the cambridge folks are very interested in this :) cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 16:38:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C759CEF9 for ; Mon, 29 Sep 2014 16:38:05 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id A38B7275 for ; Mon, 29 Sep 2014 16:38:05 +0000 (UTC) Received: from [172.16.0.139] (unknown [92.247.20.226]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 3A96555C47 for ; Mon, 29 Sep 2014 16:38:04 +0000 (UTC) Message-ID: <54298AEB.9070700@freebsd.org> Date: Mon, 29 Sep 2014 12:38:03 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: dmesg seems broken References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 16:38:05 -0000 On 09/29/2014 10:31, Chris H wrote: >> On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote: >> >>> Where can I get that information? Where was it sent? Why am I >>> not allowed to view it? >>> >> >> Sounds to me like the kernel ring buffer is now too small for all the early >> boot messages? > OK more investigation indicates that bumping > kern.msgbufsize > will return the missing bits. Maybe this is what you were trying to tell me. ;) > > Anyway. Anyone know why was this tunable reduced? I don't experience this on > RELENG_8, or 11-CURRENT. > > FWIW I have loader.conf(5) set to boot verbose. But still didn't get the info > expected. :( > > Thanks for the reply, Brandon. > > --Chris > >> >> -- >> brandon s allbery kf8nh sine nomine associates >> allbery.b@gmail.com ballbery@sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Try adding the sysctl to your loader.conf so it is set earlier I don't think the size was reduced, you may just have a lot of messages. -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 16:54:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A5D75DF for ; Mon, 29 Sep 2014 16:54:05 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68164677 for ; Mon, 29 Sep 2014 16:54:05 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j68vZ3kWGz1DP5 for ; Mon, 29 Sep 2014 12:54:02 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j68vY2n8wz1Bwm for ; Mon, 29 Sep 2014 12:54:01 -0400 (EDT) Message-ID: <201409291253590956.00E36155@smtp.24cl.home> In-Reply-To: <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Mon, 29 Sep 2014 12:53:59 -0400 From: "Mike." To: freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 16:54:05 -0000 On 9/28/2014 at 5:01 PM Steven Hartland wrote: |The only recent ATAPI change I recall is 270327, does it still occur |if you revert that? | ============= I downloaded 11-current via svn, then copied over the pre-270327 version of ata_xpt.c. make buildworld make buildkernel make installkernel reboot The looping still occurs. I haven't checked it character for character, but it the display looks to have the same or very similar information during the looping as the two pictures I posted yesterday. Thanks. Mike. btw, the Atheros WiFi card was removed, with no change in outcome. From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 17:27:15 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6DBC4A5 for ; Mon, 29 Sep 2014 17:27:15 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 928589DD for ; Mon, 29 Sep 2014 17:27:15 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 99AFC5A9F25; Mon, 29 Sep 2014 17:27:09 +0000 (UTC) Date: Mon, 29 Sep 2014 17:27:09 +0000 From: Brooks Davis To: Luigi Rizzo Subject: Re: capsicum and netmap ? Message-ID: <20140929172709.GC99239@spindle.one-eyed-alien.net> References: <20140929153043.GA78397@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: <20140929153043.GA78397@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 17:27:15 -0000 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2014 at 05:30:43PM +0200, Luigi Rizzo wrote: >=20 > Hi, > while trying the netmap-enabled libpcap library with tcpdump, i > noticed it fails to return data on a kernel with capsicum (the > string "capability mode sandbox enabled" made me suspicious, and > removing the cap_*() calls from tcpdump.c seems to make things > work again). >=20 > Would anyone be able to point me what should be done in the netmap > kernel module to make it work with capsicum ? >=20 > I am sure the cambridge folks are very interested in this :) Without knowing what modifications have been made to libpcap, it's hard to say what you need to change, but the short version is that once cap_enter is called, you must not attempt to open any file handles as that's won't work. I can't think of any other likely cause. Are all the returns of all open(), socket(), etc calls checked? In practice that means that either opening files must come earlier, or a singling mechanism needs to be added to tcpdump and libpcap to tell tcpdump not to enter capability mode when using netmap. -- Brooks --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQplm0ACgkQXY6L6fI4GtQRJQCfcYvLpO5yLtQ1YxXp72Y/Zf3i HeEAn3MalT5aN36Dr9XfKhACZgFxgc6p =KItP -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 18:15:09 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5717BC2C; Mon, 29 Sep 2014 18:15:09 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8BB33F5A; Mon, 29 Sep 2014 18:15:08 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 66BF37302E; Mon, 29 Sep 2014 20:20:08 +0200 (CEST) Date: Mon, 29 Sep 2014 20:20:08 +0200 From: Luigi Rizzo To: Brooks Davis Subject: Re: capsicum and netmap ? Message-ID: <20140929182008.GD78397@onelab2.iet.unipi.it> References: <20140929153043.GA78397@onelab2.iet.unipi.it> <20140929172709.GC99239@spindle.one-eyed-alien.net> MIME-Version: 1.0 In-Reply-To: <20140929172709.GC99239@spindle.one-eyed-alien.net> User-Agent: Mutt/1.5.20 (2009-06-14) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 18:15:09 -0000 On Mon, Sep 29, 2014 at 05:27:09PM +0000, Brooks Davis wrote: > On Mon, Sep 29, 2014 at 05:30:43PM +0200, Luigi Rizzo wrote: > > > > Hi, > > while trying the netmap-enabled libpcap library with tcpdump, i > > noticed it fails to return data on a kernel with capsicum (the > > string "capability mode sandbox enabled" made me suspicious, and > > removing the cap_*() calls from tcpdump.c seems to make things > > work again). > > > > Would anyone be able to point me what should be done in the netmap > > kernel module to make it work with capsicum ? > > > > I am sure the cambridge folks are very interested in this :) > > Without knowing what modifications have been made to libpcap, it's hard > to say what you need to change, but the short version is that once > cap_enter is called, you must not attempt to open any file handles as > that's won't work. I can't think of any other likely cause. Are all > the returns of all open(), socket(), etc calls checked? Hi Brooks, thanks for the feedback. The change (attached, with some debugging code; it dates back to december and i am trying to upstream it into FreeBSD now) is a set of methods called to open, dispatch and inject packets. > In practice that means that either opening files must come earlier, or > a singling mechanism needs to be added to tcpdump and libpcap to tell > tcpdump not to enter capability mode when using netmap. The nm_open() (which includes open and mmap) occurs before the cap_enter() call, and poll() works fine until we do the cap_enter()/cap_sandboxed() calls. I was wondering whether I should somewhat annotate the file descriptor (in the netmap kernel module) indicating that it is right to access it after cap_enter(). poll() returns 1 and errno=0 when polling for POLLIN on the netmap file descriptor, while it should return 0 (there is no traffic queued). I haven't investigated in detail but it almost looks like the underlying netmap_poll() in the device driver is not called. cheers luigi From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 18:22:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A4B3F4A; Mon, 29 Sep 2014 18:22:10 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23429CF; Mon, 29 Sep 2014 18:22:09 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8TIMRdw069558; Mon, 29 Sep 2014 11:22:33 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8TIMKEu069531; Mon, 29 Sep 2014 11:22:20 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 29 Sep 2014 11:22:22 -0700 (PDT) Message-ID: <13dd6d3eab3735353f5309a223dc1799.authenticated@ultimatedns.net> In-Reply-To: <54298AEB.9070700@freebsd.org> References: <54298AEB.9070700@freebsd.org> Date: Mon, 29 Sep 2014 11:22:22 -0700 (PDT) Subject: Re: dmesg seems broken From: "Chris H" To: "Allan Jude" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 18:22:10 -0000 > On 09/29/2014 10:31, Chris H wrote: >>> On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote: >>> >>>> Where can I get that information? Where was it sent? Why am I >>>> not allowed to view it? >>>> >>> >>> Sounds to me like the kernel ring buffer is now too small for all the early >>> boot messages? >> OK more investigation indicates that bumping >> kern.msgbufsize >> will return the missing bits. Maybe this is what you were trying to tell me. ;) >> >> Anyway. Anyone know why was this tunable reduced? I don't experience this on >> RELENG_8, or 11-CURRENT. >> >> FWIW I have loader.conf(5) set to boot verbose. But still didn't get the info >> expected. :( >> >> Thanks for the reply, Brandon. >> >> --Chris >> >>> >>> -- >>> brandon s allbery kf8nh sine nomine associates >>> allbery.b@gmail.com ballbery@sinenomine.net >>> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > Try adding the sysctl to your loader.conf so it is set earlier Thank you for the reply, Allan. I bumped kern.msgbufsize quite a bit within loader.conf. That's how I discovered that that tunable worked. But then needed to eek it down, until I found the actual top of the output -- had to bounce the box quite a few times. :P > > I don't think the size was reduced, you may just have a lot of messages. ODD. Because running RELENG_8, or 11-CURRENT on the same hardware, and yes, with BOOT_VERBOSE && VERBOSE_LOADING. I received the entire buffer. Thanks again, Allan. --Chris > > -- > Allan Jude > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 18:26:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D139B399 for ; Mon, 29 Sep 2014 18:26:00 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id AC7D8FB for ; Mon, 29 Sep 2014 18:26:00 +0000 (UTC) Received: from [172.16.0.139] (unknown [92.247.20.226]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 04E8456288 for ; Mon, 29 Sep 2014 18:25:58 +0000 (UTC) Message-ID: <5429A434.5040008@freebsd.org> Date: Mon, 29 Sep 2014 14:25:56 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: dmesg seems broken References: <54298AEB.9070700@freebsd.org> <13dd6d3eab3735353f5309a223dc1799.authenticated@ultimatedns.net> In-Reply-To: <13dd6d3eab3735353f5309a223dc1799.authenticated@ultimatedns.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 18:26:00 -0000 On 2014-09-29 14:22, Chris H wrote: >> On 09/29/2014 10:31, Chris H wrote: >>>> On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote: >>>> >>>>> Where can I get that information? Where was it sent? Why am I >>>>> not allowed to view it? >>>>> >>>> >>>> Sounds to me like the kernel ring buffer is now too small for all the early >>>> boot messages? >>> OK more investigation indicates that bumping >>> kern.msgbufsize >>> will return the missing bits. Maybe this is what you were trying to tell me. ;) >>> >>> Anyway. Anyone know why was this tunable reduced? I don't experience this on >>> RELENG_8, or 11-CURRENT. >>> >>> FWIW I have loader.conf(5) set to boot verbose. But still didn't get the info >>> expected. :( >>> >>> Thanks for the reply, Brandon. >>> >>> --Chris >>> >>>> >>>> -- >>>> brandon s allbery kf8nh sine nomine associates >>>> allbery.b@gmail.com ballbery@sinenomine.net >>>> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>> >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >> >> Try adding the sysctl to your loader.conf so it is set earlier > Thank you for the reply, Allan. > I bumped kern.msgbufsize quite a bit within loader.conf. That's how I > discovered that that tunable worked. But then needed to eek it down, > until I found the actual top of the output -- had to bounce the box > quite a few times. :P > >> >> I don't think the size was reduced, you may just have a lot of messages. > ODD. Because running RELENG_8, or 11-CURRENT on the same hardware, and yes, > with BOOT_VERBOSE && VERBOSE_LOADING. I received the entire buffer. > > Thanks again, Allan. > > --Chris > >> >> -- >> Allan Jude Do you actually see a difference in the size of kern.msgbufsize between RELENG_8 and the RELENG_9 box that is exhibiting issues? -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 18:37:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2417DCF; Mon, 29 Sep 2014 18:37:55 +0000 (UTC) Received: from udns.ultimatedns.net (unknown [IPv6:2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9483278; Mon, 29 Sep 2014 18:37:55 +0000 (UTC) Received: from udns.ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.5/8.14.5) with ESMTP id s8TIcDVu074727; Mon, 29 Sep 2014 11:38:19 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: (from www@localhost) by udns.ultimatedns.net (8.14.5/8.14.5/Submit) id s8TIc7Xv074724; Mon, 29 Sep 2014 11:38:07 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net ([2602:d1:b4d6:e600:4261:86ff:fef6:aa2a]) (UDNSMS authenticated user chrish) by ultimatedns.net with HTTP; Mon, 29 Sep 2014 11:38:07 -0700 (PDT) Message-ID: In-Reply-To: <5429A434.5040008@freebsd.org> References: <54298AEB.9070700@freebsd.org> <13dd6d3eab3735353f5309a223dc1799.authenticated@ultimatedns.net> <5429A434.5040008@freebsd.org> Date: Mon, 29 Sep 2014 11:38:07 -0700 (PDT) Subject: Re: dmesg seems broken From: "Chris H" To: "Allan Jude" User-Agent: UDNSMS/2.0.3 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 18:37:56 -0000 > On 2014-09-29 14:22, Chris H wrote: >>> On 09/29/2014 10:31, Chris H wrote: >>>>> On Sat, Sep 27, 2014 at 7:22 PM, Chris H wrote: >>>>> >>>>>> Where can I get that information? Where was it sent? Why am I >>>>>> not allowed to view it? >>>>>> >>>>> >>>>> Sounds to me like the kernel ring buffer is now too small for all the early >>>>> boot messages? >>>> OK more investigation indicates that bumping >>>> kern.msgbufsize >>>> will return the missing bits. Maybe this is what you were trying to tell me. ;) >>>> >>>> Anyway. Anyone know why was this tunable reduced? I don't experience this on >>>> RELENG_8, or 11-CURRENT. >>>> >>>> FWIW I have loader.conf(5) set to boot verbose. But still didn't get the info >>>> expected. :( >>>> >>>> Thanks for the reply, Brandon. >>>> >>>> --Chris >>>> >>>>> >>>>> -- >>>>> brandon s allbery kf8nh sine nomine associates >>>>> allbery.b@gmail.com ballbery@sinenomine.net >>>>> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>>> >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>>> >>> >>> Try adding the sysctl to your loader.conf so it is set earlier >> Thank you for the reply, Allan. >> I bumped kern.msgbufsize quite a bit within loader.conf. That's how I >> discovered that that tunable worked. But then needed to eek it down, >> until I found the actual top of the output -- had to bounce the box >> quite a few times. :P >> >>> >>> I don't think the size was reduced, you may just have a lot of messages. >> ODD. Because running RELENG_8, or 11-CURRENT on the same hardware, and yes, >> with BOOT_VERBOSE && VERBOSE_LOADING. I received the entire buffer. >> >> Thanks again, Allan. >> >> --Chris >> >>> >>> -- >>> Allan Jude > > Do you actually see a difference in the size of kern.msgbufsize between > RELENG_8 and the RELENG_9 box that is exhibiting issues? Good question! I was afraid you'd ask me that. I was so anxious to get past this, and get all the tasks queued for this box. I entered the sysctl, and just as I hit the enter key. It hit me; I need to record the results of the value it _currently_ has -- D'OH! I'm going to be performing the same task on a nearly identical piece of hardware later this week. I'll record the value(s) (for RELENG_8, RELENG_9 && 11), and report back. Thanks, and sorry for having done "the right thing(tm)". :P --Chris > > -- > Allan Jude > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 18:53:09 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C6D9267 for ; Mon, 29 Sep 2014 18:53:09 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 352B6666 for ; Mon, 29 Sep 2014 18:53:08 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 135F05A9F24; Mon, 29 Sep 2014 18:53:08 +0000 (UTC) Date: Mon, 29 Sep 2014 18:53:08 +0000 From: Brooks Davis To: Luigi Rizzo Subject: Re: capsicum and netmap ? Message-ID: <20140929185308.GD99239@spindle.one-eyed-alien.net> References: <20140929153043.GA78397@onelab2.iet.unipi.it> <20140929172709.GC99239@spindle.one-eyed-alien.net> <20140929182008.GD78397@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zS7rBR6csb6tI2e1" Content-Disposition: inline In-Reply-To: <20140929182008.GD78397@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 18:53:09 -0000 --zS7rBR6csb6tI2e1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2014 at 08:20:08PM +0200, Luigi Rizzo wrote: > On Mon, Sep 29, 2014 at 05:27:09PM +0000, Brooks Davis wrote: > > On Mon, Sep 29, 2014 at 05:30:43PM +0200, Luigi Rizzo wrote: > > >=20 > > > Hi, > > > while trying the netmap-enabled libpcap library with tcpdump, i > > > noticed it fails to return data on a kernel with capsicum (the > > > string "capability mode sandbox enabled" made me suspicious, and > > > removing the cap_*() calls from tcpdump.c seems to make things > > > work again). > > >=20 > > > Would anyone be able to point me what should be done in the netmap > > > kernel module to make it work with capsicum ? > > >=20 > > > I am sure the cambridge folks are very interested in this :) > >=20 > > Without knowing what modifications have been made to libpcap, it's hard > > to say what you need to change, but the short version is that once > > cap_enter is called, you must not attempt to open any file handles as > > that's won't work. I can't think of any other likely cause. Are all > > the returns of all open(), socket(), etc calls checked? >=20 > Hi Brooks, > thanks for the feedback. >=20 > The change (attached, with some debugging code; it dates back to > december and i am trying to upstream it into FreeBSD now) is a set > of methods called to open, dispatch and inject packets. >=20 > > In practice that means that either opening files must come earlier, or > > a singling mechanism needs to be added to tcpdump and libpcap to tell > > tcpdump not to enter capability mode when using netmap. >=20 > The nm_open() (which includes open and mmap) occurs before the > cap_enter() call, and poll() works fine until we do the > cap_enter()/cap_sandboxed() calls. >=20 > I was wondering whether I should somewhat annotate the file descriptor > (in the netmap kernel module) indicating that it is right to access it > after cap_enter(). poll() returns 1 and errno=3D0 > when polling for POLLIN on the netmap file descriptor, > while it should return 0 (there is no traffic queued). >=20 > I haven't investigated in detail but it almost looks like the > underlying netmap_poll() in the device driver is not called. Ah, that's it. The problem is that we're limiting the pcap file descriptors to CAP_READ. It looks like you'd need to add CAP_EVENT to that list. Look for cap_rights_init and cap_rights_limit pairs to find the right place(s) to modify. -- Brooks --zS7rBR6csb6tI2e1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQpqpMACgkQXY6L6fI4GtRYQQCfTLk0ftRawbsSx+yK4gXxHHAu R7QAn2WKpNoN6PEPCKDpYM/HDXSLXJkx =z6NE -----END PGP SIGNATURE----- --zS7rBR6csb6tI2e1-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 19:24:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C67267FB for ; Mon, 29 Sep 2014 19:24:37 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93725A62 for ; Mon, 29 Sep 2014 19:24:37 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j6DFH22Fyz1DPw for ; Mon, 29 Sep 2014 15:24:35 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j6DFG3mTNz1C2H for ; Mon, 29 Sep 2014 15:24:34 -0400 (EDT) Message-ID: <201409291524330248.016D379A@smtp.24cl.home> In-Reply-To: <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Mon, 29 Sep 2014 15:24:33 -0400 From: "Mike." To: freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 19:24:37 -0000 On 9/28/2014 at 5:01 PM Steven Hartland wrote: |The only recent ATAPI change I recall is 270327, does it still occur |if you revert that? | | Regards | Steve ============= Another data point. I just downloaded the image: FreeBSD-10.1-BETA3-i386-disc1 The looping occurs also with that CD. Perhaps this is not caused by a recent change? From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 19:40:18 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D298D26; Mon, 29 Sep 2014 19:40:18 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id D35F8C44; Mon, 29 Sep 2014 19:40:17 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E2F0773027; Mon, 29 Sep 2014 21:45:17 +0200 (CEST) Date: Mon, 29 Sep 2014 21:45:17 +0200 From: Luigi Rizzo To: Brooks Davis Subject: Re: capsicum and netmap ? Message-ID: <20140929194517.GE78397@onelab2.iet.unipi.it> References: <20140929153043.GA78397@onelab2.iet.unipi.it> <20140929172709.GC99239@spindle.one-eyed-alien.net> <20140929182008.GD78397@onelab2.iet.unipi.it> <20140929185308.GD99239@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140929185308.GD99239@spindle.one-eyed-alien.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 19:40:18 -0000 On Mon, Sep 29, 2014 at 06:53:08PM +0000, Brooks Davis wrote: > On Mon, Sep 29, 2014 at 08:20:08PM +0200, Luigi Rizzo wrote: ... > > The nm_open() (which includes open and mmap) occurs before the > > cap_enter() call, and poll() works fine until we do the > > cap_enter()/cap_sandboxed() calls. > > > > I was wondering whether I should somewhat annotate the file descriptor > > (in the netmap kernel module) indicating that it is right to access it > > after cap_enter(). poll() returns 1 and errno=0 > > when polling for POLLIN on the netmap file descriptor, > > while it should return 0 (there is no traffic queued). > > > > I haven't investigated in detail but it almost looks like the > > underlying netmap_poll() in the device driver is not called. > > Ah, that's it. The problem is that we're limiting the pcap file > descriptors to CAP_READ. It looks like you'd need to add CAP_EVENT to > that list. Look for cap_rights_init and cap_rights_limit pairs to find > the right place(s) to modify. > The following works for me with the netmap file descriptor, but I am not sure if it is too tight or too loose. Also I don't understand why regular bpf did not need CAP_EVENT (I presume it worked correctly or people would have complained ?) cheers luigi Index: ../../contrib/tcpdump/tcpdump.c =================================================================== --- ../../contrib/tcpdump/tcpdump.c (revision 269180) +++ ../../contrib/tcpdump/tcpdump.c (working copy) @@ -1486,7 +1486,7 @@ if (RFileName == NULL && VFileName == NULL) { static const unsigned long cmds[] = { BIOCGSTATS }; - cap_rights_init(&rights, CAP_IOCTL, CAP_READ); + cap_rights_init(&rights, CAP_IOCTL, CAP_READ, CAP_EVENT); if (cap_rights_limit(pcap_fileno(pd), &rights) < 0 && errno != ENOSYS) { error("unable to limit pcap descriptor"); @@ -1519,7 +1519,7 @@ if (p == NULL) error("%s", pcap_geterr(pd)); #ifdef __FreeBSD__ - cap_rights_init(&rights, CAP_SEEK, CAP_WRITE); + cap_rights_init(&rights, CAP_SEEK, CAP_WRITE, CAP_EVENT); if (cap_rights_limit(fileno(pcap_dump_file(p)), &rights) < 0 && errno != ENOSYS) { error("unable to limit dump descriptor"); @@ -1662,7 +1662,7 @@ if (pd == NULL) error("%s", ebuf); #ifdef __FreeBSD__ - cap_rights_init(&rights, CAP_READ); + cap_rights_init(&rights, CAP_READ, CAP_EVENT); if (cap_rights_limit(fileno(pcap_file(pd)), &rights) < 0 && errno != ENOSYS) { error("unable to limit pcap descriptor"); From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 20:03:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D22C86E for ; Mon, 29 Sep 2014 20:03:48 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B512EDD for ; Mon, 29 Sep 2014 20:03:48 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j6F6W04tyz1DQc for ; Mon, 29 Sep 2014 16:03:47 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j6F6V11R1z1C2Q for ; Mon, 29 Sep 2014 16:03:46 -0400 (EDT) Message-ID: <201409291603440911.019119CE@smtp.24cl.home> In-Reply-To: <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Mon, 29 Sep 2014 16:03:44 -0400 From: "Mike." To: freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 20:03:48 -0000 On 9/28/2014 at 5:01 PM Steven Hartland wrote: |The only recent ATAPI change I recall is 270327, does it still occur |if you revert that? | | Regards | Steve ============= Yet another data point (actually two data points). I had an older STABLE image sitting around. FreeBSD-10.0-STABLE-i386-20140712-r268571-disc1 The looping occurs also with that CD. And, finally, the looping does not occur with 10.0-RELEASE. This release seems to be able to recover from the timeouts. So that should put a time bracket on the issue, roughly the first half of 2014. From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 21:04:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B9BBC70 for ; Mon, 29 Sep 2014 21:04:03 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC1D3803 for ; Mon, 29 Sep 2014 21:04:01 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8TL45MG095075; Mon, 29 Sep 2014 21:04:05 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: "Mike." , freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Date: Mon, 29 Sep 2014 23:04:00 +0200 Message-Id: <20140929210142.M26034@beckpeccoz.com> In-Reply-To: <201409291603440911.019119CE@smtp.24cl.home> References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409291603440911.019119CE@smtp.24cl.home> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 213.37.0.220 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 21:04:03 -0000 Hi Mike, On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote [...] > So that should put a time bracket on the issue, roughly the first > half of 2014. can you boot 271146? Just buildkernel and installkernel. Thank you. BR, -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Mon Sep 29 21:53:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D20EDEFC; Mon, 29 Sep 2014 21:53:48 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4797AD19; Mon, 29 Sep 2014 21:53:47 +0000 (UTC) X-AuditID: 1209190f-f79aa6d000005b45-d8-5429d3b72ffe Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B4.C9.23365.7B3D9245; Mon, 29 Sep 2014 17:48:39 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s8TLmcxG002935; Mon, 29 Sep 2014 17:48:39 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s8TLmaVo031029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Sep 2014 17:48:38 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s8TLmarR012072; Mon, 29 Sep 2014 17:48:36 -0400 (EDT) Date: Mon, 29 Sep 2014 17:48:36 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: FreeBSD Current , "freebsd-hackers@freebsd.org" Subject: Re: Call for FreeBSD 2014Q3 (July-September) Status Reports In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrbv9smaIwYcL6ha7rp1mt5jz5gOT xfbN/xgdmD1mfJrPEsAYxWWTkpqTWZZapG+XwJWxteUZc8EMnorn21+wNTD+5Oxi5OSQEDCR ePz5GDuELSZx4d56ti5GLg4hgdlMEh82HGWHcDYySuy9socZpEpI4BCTRO8nZYhEA6PEuo09 jCAJFgFtiaUXP4KNYhNQk3i8t5kVYqyixOZTk8CaRQTKJb42ngGrFxZwkbj2vZcFxOYUCJRY t2MqWJxXwFFibkcnG8SyAImnUyeCzREV0JFYvX8KC0SNoMTJmU/AbGYBLYnl07exTGAUnIUk NQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTSTYzgUJXk38H47aDSIUYB DkYlHl6OFRohQqyJZcWVuYcYJTmYlER5353QDBHiS8pPqcxILM6ILyrNSS0+xCjBwawkwiu3 AyjHm5JYWZValA+TkuZgURLn3fSDL0RIID2xJDU7NbUgtQgmK8PBoSTB++ESUKNgUWp6akVa Zk4JQpqJgxNkOA/Q8MUgNbzFBYm5xZnpEPlTjLoc6zq/9TMJseTl56VKifM+uwhUJABSlFGa BzcHlmJeMYoDvSXMuxtkFA8wPcFNegW0hAloSdoGdZAlJYkIKakGRv6J2dfuyW3sUJXx1Et+ GtN3ZDrTL7OTh7dE3DCdOmVRv8KJEwcmrtfy3MOffdD+y36eaXsETm9oE74Y7Oh0wL4+JF36 9ja5wmUHo/fMjr4iNV9ki/n9yhdKM7qyAtedMJL9FhX3wO+TSGbxTatAsYKpG1R7TtzgneGf sc7f/tHfWNHNJ/wZNyuxFGckGmoxFxUnAgDGX/ZLDAMAAA== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 21:53:49 -0000 Reminder: the deadline for 2014Q3 status reports is just over a week away! Thanks, Ben (on behalf of monthly@) On Tue, 2 Sep 2014, Ed Maste wrote: > Dear FreeBSD Community, > > The deadline for the next FreeBSD Quarterly Status update is October 7, > for work done in July through September. > > Status report submissions do not have to be very long. They may be > about anything happening in the FreeBSD project and community, and > provide a great way to inform FreeBSD users and developers about what > you're working on. Submission of reports is not restricted to > committers. Anyone doing anything interesting and FreeBSD-related > can -- and should -- write one! > > The preferred and easiest submission method is to use the XML > generator [1] with the results emailed to the status report team at > monthly@freebsd.org . There is also an XML template [2] which can be > filled out manually and attached if preferred. For the expected > content and style, please study our guidelines on how to write a good > status report [3]. You can also review previous issues [4][5] for > ideas on the style and format. > > We are looking forward to all of your 2014Q3 reports! > > Thanks, > Ed (on behalf of monthly@) > > > [1] http://www.freebsd.org/cgi/monthly.cgi > [2] http://www.freebsd.org/news/status/report-sample.xml > [3] http://www.freebsd.org/news/status/howto.html > [4] http://www.freebsd.org/news/status/report-2014-01-2014-03.html > [4] http://www.freebsd.org/news/status/report-2014-04-2014-06.html From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 01:57:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7DCB2A9 for ; Tue, 30 Sep 2014 01:57:49 +0000 (UTC) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E6063D8 for ; Tue, 30 Sep 2014 01:57:49 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id lj1so3889054pab.10 for ; Mon, 29 Sep 2014 18:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent; bh=WXvlKK1SA2OapcPVZKU+pf9n9ImeuMVax+7P97y2PoA=; b=AKUlSMvOUtVSzkawjbgcb0WOlaRBVe25fukD9VDfpV8GRuO08WFvBOwIJr4WXm804R Er/AwIKXeZ0F3KNceRqpad4Tifkc1CsZFff/2nZHmcb9x1tTtR5R/EGMR7Fd1o9i3s1e cEc7ih7jwniq5nkIPx2u55hS2h5J1/VCPWaYwqgxIZNguidabYkqmCAuZjq7R+qDaRKW iq8rJBPXKd4LT874WbhEhHc2Q+l6KZgu+U0nXDnsO3sm53NVzeBGaD/5cjfMLDDv+gew KdqHccDJwJ0H4n8ZyoTOfkAlLYvo/Yr0IkNYiAKRVdzD1wHCLeX4+zpIRrk3JLkmmN35 GjqQ== X-Received: by 10.68.233.68 with SMTP id tu4mr67119478pbc.65.1412042269174; Mon, 29 Sep 2014 18:57:49 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id d9sm214582pdm.5.2014.09.29.18.57.45 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 29 Sep 2014 18:57:47 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 30 Sep 2014 10:57:41 +0900 Date: Tue, 30 Sep 2014 10:57:41 +0900 To: freebsd-current@freebsd.org Subject: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support Message-ID: <20140930015741.GA2451@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 01:57:49 -0000 Hi, I've added support for QAC AR816x/AR817x ethernet controllers. It passed my limited testing and I need more testers. You can find patches from the following URLs. http://people.freebsd.org/~yongari/alc/pci.quirk.diff and http://people.freebsd.org/~yongari/alc/alc.diff.20140930 pci.qurik.diff is to workaround silicon bug of AR816x. Without it MSI/MSIX interrupt wouldn't work. If you just want to use legacy INTx interrupt you don't have to apply it but you have to tell alc(4) not to use MSI/MSIX interrupt with tunables( hw.alc.msi.disable and hw.alc.msix_disable). alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172 and E2200 controllers. It supports all hardware features except RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x controllers please test and report how the diff works for you. Thanks. From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 03:41:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF25695B for ; Tue, 30 Sep 2014 03:41:16 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 695A69F for ; Tue, 30 Sep 2014 03:41:15 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XYoJF-0008QG-4F for freebsd-current@freebsd.org; Tue, 30 Sep 2014 05:41:05 +0200 Received: from 97-96-57-7.res.bhn.net ([97.96.57.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Sep 2014 05:41:05 +0200 Received: from dpejesh by 97-96-57-7.res.bhn.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Sep 2014 05:41:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: David Shane Holden Subject: [PATCH] nscd Date: Mon, 29 Sep 2014 23:40:52 -0400 Lines: 62 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010309000609020107080506" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 97-96-57-7.res.bhn.net User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 03:41:16 -0000 This is a multi-part message in MIME format. --------------010309000609020107080506 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit So, I've noticed nscd hasn't worked right for awhile now. Since I upgraded to 10.0 it never seemed to cache properly but I never bothered to really dig into it until recently and here's what I've found. In my environment I have nsswitch set to use caching and LDAP as such: group: files cache ldap passwd: files cache ldap The LDAP part works fine, but caching didn't on 10.0 for some reason. On my 9.2 machines it works as expected though. What I've found is in usr.sbin/nscd/query.c struct query_state * init_query_state(int sockfd, size_t kevent_watermark, uid_t euid, gid_t egid) { ... memcpy(&retval->timeout, &s_configuration->query_timeout, sizeof(struct timeval)); ... } s_configuration->query_timeout is an 'int' which is being memcpy'd into a 'struct timeval' causing it to grab other parts of the s_configuration struct along with the query_timeout value and polluting retval->timeout. In this case it appears to be grabbing s_configuration->threads_num and shoving that into timeout.tv_sec along with the query_timeout. This ends up confusing nscd later on (instead of being 8 it ends up being set to 34359738376) and breaks it's ability to cache. I've attached a patch to set the retval->timeout properly and gets nscd working again. I'm guessing gcc was handling this differently from clang which is why it wasn't a problem before 10.0. --------------010309000609020107080506 Content-Type: text/x-patch; name="nscd.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="nscd.patch" diff --git a/usr.sbin/nscd/query.c b/usr.sbin/nscd/query.c index c233e19..abd8fab 100644 --- a/usr.sbin/nscd/query.c +++ b/usr.sbin/nscd/query.c @@ -1253,8 +1253,8 @@ init_query_state(int sockfd, size_t kevent_watermark, uid_t euid, gid_t egid) retval->read_func = query_socket_read; get_time_func(&retval->creation_time); - memcpy(&retval->timeout, &s_configuration->query_timeout, - sizeof(struct timeval)); + retval->timeout.tv_usec = 0; + retval->timeout.tv_sec = s_configuration->query_timeout; TRACE_OUT(init_query_state); return (retval); --------------010309000609020107080506-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 05:48:20 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47A35C51; Tue, 30 Sep 2014 05:48:20 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 24065DE1; Tue, 30 Sep 2014 05:48:18 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA16503; Tue, 30 Sep 2014 08:48:10 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XYqIE-000Fpw-2i; Tue, 30 Sep 2014 08:48:10 +0300 Message-ID: <542A43E1.5010401@FreeBSD.org> Date: Tue, 30 Sep 2014 08:47:13 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: FreeBSD Current Subject: vt_suspend / vt_resume Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 05:48:20 -0000 I think that currently vt_suspend / vt_resume are called at quite unsuitable times. For example, vt_suspend performs a vt switch which requires cooperation from an X server, but that could be problematic given that some devices may already be suspended. I believe that it is better to do what sc(4) does and use power_suspend / power_resume event handlers instead of device_suspend / device_resume methods. power_suspend event is posted when a kernel has not entered any special state yet. What do you think? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 06:13:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B379D178; Tue, 30 Sep 2014 06:13:14 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6ECABF2; Tue, 30 Sep 2014 06:13:14 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XYqgM-001t6M-Kl>; Tue, 30 Sep 2014 08:13:06 +0200 Received: from f052143071.adsl.alicedsl.de ([78.52.143.71] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XYqgM-003eNJ-HA>; Tue, 30 Sep 2014 08:13:06 +0200 Date: Tue, 30 Sep 2014 08:13:01 +0200 From: "O. Hartmann" To: FreeBSD CURRENT , FreeBSD Ports Subject: pkg/ports system terribly messed up? Message-ID: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/AFG.sut9tWCkpA6z9jS3Emt"; protocol="application/pgp-signature" X-Originating-IP: 78.52.143.71 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 06:13:14 -0000 --Sig_/AFG.sut9tWCkpA6z9jS3Emt Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello. I just made the last update of the ports yesterday (I use portmaster -da pe= rforming this task) and obviously or superficially everything went all right. I'm running on the boxes in question most recent CURRENT. On one system, a subsequent start of updating ports starts to freak out whe= n updateing lang/gcc: it loops over and over on some ports already updated, especially devel/binutils, but the port looping on isn't specific and varies. On every CURRENT box I tried this morning to update the ports again, I find= this frsutrating message (depends on installation, but it seems in principal the= same, only the affected ports in dependency chain varies): =3D=3D=3D>>> Gathering distinfo list for installed ports =3D=3D=3D>>> Starting check of installed ports for available updates =3D=3D=3D>>> Launching child to update openldap-sasl-client-2.4.39_2 to openldap-sasl-client-2.4.40 =3D=3D=3D>>> All >> openldap-sasl-client-2.4.39_2 (1/1) =3D=3D=3D>>> Currently installed version: openldap-sasl-client-2.4.39_2 =3D=3D=3D>>> Port directory: /usr/ports/net/openldap24-sasl-client =3D=3D=3D>>> Launching 'make checksum' for net/openldap24-sasl-client in ba= ckground =3D=3D=3D>>> Gathering dependency list for net/openldap24-sasl-client from = ports =3D=3D=3D>>> Launching child to install net/openldap24-sasl-client/../../po= rts-mgmt/pkg =3D=3D=3D>>> All >> openldap-sasl-client-2.4.39_2 >> net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2) =3D=3D=3D>>> Port directory: /usr/ports/net/openldap24-sasl-client/../../po= rts-mgmt/pkg =3D=3D=3D>>> Update for net/openldap24-sasl-client/../../ports-mgmt/pkg fai= led =3D=3D=3D>>> Aborting update =3D=3D=3D>>> Update for openldap-sasl-client-2.4.39_2 failed =3D=3D=3D>>> Aborting update You have new mail. This isn't, so far, OpenLDAP specific, on other systems without LDAP the up= date fails on another port. Oliver --Sig_/AFG.sut9tWCkpA6z9jS3Emt Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUKknyAAoJEOgBcD7A/5N8EcYIAL+Smy3ns0xZRn5KoDRUiJ4m 6zUvfTCQ8IdW3zq7oIjS+PWehj+G6+aIJFvZFiWb8Cu72diHMnnCX48kcAL7w8XR UlJRFgMw34RORBuThE8UfgTR5fUnGWLKC12f0STWq3T9EbjIob9mnfMfA5Xwrh3F AG0Nc64CQ4Yz7NjDIpJYSTGRJ1nbrUtmNW+Adrg8PTmYZvlo6KqZvmJaeOe/Gl/g wgcH79ov3zIHpyZkJI4qStqVyuAM+5cc3RzAXQ0HkX7K8NAYa2ZbxsGZsu0Uu0+n FZ+Gv+hnf80EsmuzFV/q2w6aUduMQT09Rmn2NpGOh/vaj3ksRnJ1Vj94/QnuUqk= =9uPL -----END PGP SIGNATURE----- --Sig_/AFG.sut9tWCkpA6z9jS3Emt-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 06:40:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF85D942; Tue, 30 Sep 2014 06:40:26 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 857B963E; Tue, 30 Sep 2014 06:40:26 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id s8U6eJnb006273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Sep 2014 08:40:19 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id s8U6eJP5006270; Tue, 30 Sep 2014 08:40:19 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Tue, 30 Sep 2014 08:40:19 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: "O. Hartmann" Subject: Re: pkg/ports system terribly messed up? In-Reply-To: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> Message-ID: References: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD CURRENT , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 06:40:27 -0000 On Tue, 30 Sep 2014 08:13+0200, O. Hartmann wrote: > > Hello. > > I just made the last update of the ports yesterday (I use portmaster -da performing this > task) and obviously or superficially everything went all right. > > I'm running on the boxes in question most recent CURRENT. > > On one system, a subsequent start of updating ports starts to freak out when updateing > lang/gcc: it loops over and over on some ports already updated, especially > devel/binutils, but the port looping on isn't specific and varies. > > On every CURRENT box I tried this morning to update the ports again, I find this > frsutrating message (depends on installation, but it seems in principal the same, only > the affected ports in dependency chain varies): > > ===>>> Gathering distinfo list for installed ports > > ===>>> Starting check of installed ports for available updates > ===>>> Launching child to update openldap-sasl-client-2.4.39_2 to > openldap-sasl-client-2.4.40 > > ===>>> All >> openldap-sasl-client-2.4.39_2 (1/1) > > ===>>> Currently installed version: openldap-sasl-client-2.4.39_2 > ===>>> Port directory: /usr/ports/net/openldap24-sasl-client > > ===>>> Launching 'make checksum' for net/openldap24-sasl-client in background > ===>>> Gathering dependency list for net/openldap24-sasl-client from ports > ===>>> Launching child to install net/openldap24-sasl-client/../../ports-mgmt/pkg > > ===>>> All >> openldap-sasl-client-2.4.39_2 >> > net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2) > > ===>>> Port directory: /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg > > > ===>>> Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed > ===>>> Aborting update > > ===>>> Update for openldap-sasl-client-2.4.39_2 failed > ===>>> Aborting update > > You have new mail. > > > This isn't, so far, OpenLDAP specific, on other systems without LDAP the update fails on > another port. > > Oliver What happens if you manually upgrade ports-mgmt/pkg, assuming it's out of date? I've noticed running make missing from /usr/ports/ports-mgmt/pkg produces some interesting results _only_ when pkg is up-to-date: trond@enterprise:/usr/ports/ports-mgmt/pkg>make missing /usr/ports/workdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.3.8/src/pkg-static: not found *** [missing] Error code 127 Stop in /usr/ports/ports-mgmt/pkg. Using portupgrade, I finally created a script to help me get past some of the deficiency of the duo pkg and portupgrade. The script checks to see if ports-mgmt/pkg needs an upgrade and upgrades pkg before proceeding with the remaining outdated ports. As portupgrade doesn't always properly install _new_ dependencies, my script also checks for any missing ports and installs them prior to upgrading the outdated ports. If anyone's interested, here's my script: http://ximalas.info/~trond/create-zfs/canmount/upgrade-outdated-ports.sh -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 06:43:45 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 113E2B0E; Tue, 30 Sep 2014 06:43:45 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E9B2671; Tue, 30 Sep 2014 06:43:44 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id s8U6hdtC006299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Sep 2014 08:43:39 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id s8U6hdYZ006296; Tue, 30 Sep 2014 08:43:39 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Tue, 30 Sep 2014 08:43:39 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: "O. Hartmann" Subject: Re: pkg/ports system terribly messed up? In-Reply-To: Message-ID: References: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD CURRENT , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 06:43:45 -0000 On Tue, 30 Sep 2014 08:40+0200, Trond Endrestøl wrote: > On Tue, 30 Sep 2014 08:13+0200, O. Hartmann wrote: > > > > > Hello. > > > > I just made the last update of the ports yesterday (I use portmaster -da performing this > > task) and obviously or superficially everything went all right. > > > > I'm running on the boxes in question most recent CURRENT. > > > > On one system, a subsequent start of updating ports starts to freak out when updateing > > lang/gcc: it loops over and over on some ports already updated, especially > > devel/binutils, but the port looping on isn't specific and varies. > > > > On every CURRENT box I tried this morning to update the ports again, I find this > > frsutrating message (depends on installation, but it seems in principal the same, only > > the affected ports in dependency chain varies): > > > > ===>>> Gathering distinfo list for installed ports > > > > ===>>> Starting check of installed ports for available updates > > ===>>> Launching child to update openldap-sasl-client-2.4.39_2 to > > openldap-sasl-client-2.4.40 > > > > ===>>> All >> openldap-sasl-client-2.4.39_2 (1/1) > > > > ===>>> Currently installed version: openldap-sasl-client-2.4.39_2 > > ===>>> Port directory: /usr/ports/net/openldap24-sasl-client > > > > ===>>> Launching 'make checksum' for net/openldap24-sasl-client in background > > ===>>> Gathering dependency list for net/openldap24-sasl-client from ports > > ===>>> Launching child to install net/openldap24-sasl-client/../../ports-mgmt/pkg > > > > ===>>> All >> openldap-sasl-client-2.4.39_2 >> > > net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2) > > > > ===>>> Port directory: /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg > > > > > > ===>>> Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed > > ===>>> Aborting update > > > > ===>>> Update for openldap-sasl-client-2.4.39_2 failed > > ===>>> Aborting update > > > > You have new mail. > > > > > > This isn't, so far, OpenLDAP specific, on other systems without LDAP the update fails on > > another port. > > > > Oliver > > What happens if you manually upgrade ports-mgmt/pkg, assuming it's out > of date? > > I've noticed running make missing from /usr/ports/ports-mgmt/pkg > produces some interesting results _only_ when pkg is up-to-date: > > trond@enterprise:/usr/ports/ports-mgmt/pkg>make missing > /usr/ports/workdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.3.8/src/pkg-static: not found > *** [missing] Error code 127 > > Stop in /usr/ports/ports-mgmt/pkg. > > Using portupgrade, I finally created a script to help me get past some Oh, that's bad wording on my part, it should read: I'm only using portupgrade, so I finally created a script to help me get past some > of the deficiency of the duo pkg and portupgrade. The script checks to > see if ports-mgmt/pkg needs an upgrade and upgrades pkg before > proceeding with the remaining outdated ports. As portupgrade doesn't > always properly install _new_ dependencies, my script also checks for > any missing ports and installs them prior to upgrading the outdated > ports. If anyone's interested, here's my script: > http://ximalas.info/~trond/create-zfs/canmount/upgrade-outdated-ports.sh -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 06:56:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BFF0ED25; Tue, 30 Sep 2014 06:56:14 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D12D7AB; Tue, 30 Sep 2014 06:56:13 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XYrM4-0026fq-8H>; Tue, 30 Sep 2014 08:56:12 +0200 Received: from f052143071.adsl.alicedsl.de ([78.52.143.71] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XYrM4-003k0c-5D>; Tue, 30 Sep 2014 08:56:12 +0200 Date: Tue, 30 Sep 2014 08:56:09 +0200 From: "O. Hartmann" To: Trond =?ISO-8859-1?Q?Endrest=F8l?= Subject: Re: pkg/ports system terribly messed up? Message-ID: <20140930085609.3f54d01f.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/L=SC4_WMNXcfYl7AmHe0.Q_"; protocol="application/pgp-signature" X-Originating-IP: 78.52.143.71 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 06:56:14 -0000 --Sig_/L=SC4_WMNXcfYl7AmHe0.Q_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Am Tue, 30 Sep 2014 08:40:19 +0200 (CEST) Trond Endrest=F8l schrieb: > On Tue, 30 Sep 2014 08:13+0200, O. Hartmann wrote: >=20 > >=20 > > Hello. > >=20 > > I just made the last update of the ports yesterday (I use portmaster -d= a performing > > this task) and obviously or superficially everything went all right. > >=20 > > I'm running on the boxes in question most recent CURRENT. > >=20 > > On one system, a subsequent start of updating ports starts to freak out= when updateing > > lang/gcc: it loops over and over on some ports already updated, especia= lly > > devel/binutils, but the port looping on isn't specific and varies. > >=20 > > On every CURRENT box I tried this morning to update the ports again, I = find this > > frsutrating message (depends on installation, but it seems in principal= the same, only > > the affected ports in dependency chain varies): > >=20 > > =3D=3D=3D>>> Gathering distinfo list for installed ports > >=20 > > =3D=3D=3D>>> Starting check of installed ports for available updates > > =3D=3D=3D>>> Launching child to update openldap-sasl-client-2.4.39_2 to > > openldap-sasl-client-2.4.40 > >=20 > > =3D=3D=3D>>> All >> openldap-sasl-client-2.4.39_2 (1/1) > >=20 > > =3D=3D=3D>>> Currently installed version: openldap-sasl-client-2.4.39_2 > > =3D=3D=3D>>> Port directory: /usr/ports/net/openldap24-sasl-client > >=20 > > =3D=3D=3D>>> Launching 'make checksum' for net/openldap24-sasl-client i= n background > > =3D=3D=3D>>> Gathering dependency list for net/openldap24-sasl-client f= rom ports > > =3D=3D=3D>>> Launching child to install net/openldap24-sasl-client/../.= ./ports-mgmt/pkg > >=20 > > =3D=3D=3D>>> All >> openldap-sasl-client-2.4.39_2 >> > > net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2) > >=20 > > =3D=3D=3D>>> Port directory: /usr/ports/net/openldap24-sasl-client/../.= ./ports-mgmt/pkg > >=20 > >=20 > > =3D=3D=3D>>> Update for net/openldap24-sasl-client/../../ports-mgmt/pkg= failed > > =3D=3D=3D>>> Aborting update > >=20 > > =3D=3D=3D>>> Update for openldap-sasl-client-2.4.39_2 failed > > =3D=3D=3D>>> Aborting update > >=20 > > You have new mail. > >=20 > >=20 > > This isn't, so far, OpenLDAP specific, on other systems without LDAP th= e update fails > > on another port. > >=20 > > Oliver >=20 > What happens if you manually upgrade ports-mgmt/pkg, assuming it's out=20 > of date? I tried this already, each port in particular, reinstalled via "make clean = reinstall clean" works fine. I did this with ports-mgnt/pkg and ports-mgmt/portmaster= in the first place. >=20 > I've noticed running make missing from /usr/ports/ports-mgmt/pkg=20 > produces some interesting results _only_ when pkg is up-to-date: >=20 > trond@enterprise:/usr/ports/ports-mgmt/pkg>make missing > /usr/ports/workdirs/usr/ports/ports-mgmt/pkg/work/pkg-1.3.8/src/pkg-stati= c: not found > *** [missing] Error code 127 >=20 > Stop in /usr/ports/ports-mgmt/pkg. >=20 > Using portupgrade, I finally created a script to help me get past some=20 > of the deficiency of the duo pkg and portupgrade. The script checks to=20 > see if ports-mgmt/pkg needs an upgrade and upgrades pkg before=20 > proceeding with the remaining outdated ports. As portupgrade doesn't=20 > always properly install _new_ dependencies, my script also checks for=20 > any missing ports and installs them prior to upgrading the outdated=20 > ports. If anyone's interested, here's my script:=20 > http://ximalas.info/~trond/create-zfs/canmount/upgrade-outdated-ports.sh >=20 I'm running portmaster and an update of ports now on an Laptop with CURRENT= that hasn't been touched for two days by now and there the update runs quite well and p= asses through. All boxes I ran an update of ports by yesterday fail! --Sig_/L=SC4_WMNXcfYl7AmHe0.Q_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUKlQJAAoJEOgBcD7A/5N8qjkIANpoGeCDoNbQhfEcYpBi6cZ3 1HpreTm8KjAld4fe41mEr4k+UChWoWJCU0RfbL+naylQa7O6m/4mwNrqBmnVlTsA 8OkKDKGpXC6KsMB5lPZaL+BOIYZY8rKlFBb0fY4djvbqKIQhb6OpE6I2ZkZkfqKT d8qa9cWd4f6ib+bIkLA9gi6HluDZi0SbK2gzKJfpmcvFSsjoXCKpR/69CezWVRxc 8SCEFECO+Vdbsnm7UTfk135D8I4f/KaP4xj9pyUH6d34UsmPxVaX3y26yklwdAEV C87KMh83o4Fd3hbU+ZWmtga4ZXIE6OrfzCgHeztZ1jUCJ40fkMnIzELJNdlzYWA= =WKew -----END PGP SIGNATURE----- --Sig_/L=SC4_WMNXcfYl7AmHe0.Q_-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 07:22:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3730D191 for ; Tue, 30 Sep 2014 07:22:49 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF80A7E for ; Tue, 30 Sep 2014 07:22:48 +0000 (UTC) Received: from [172.16.0.139] (unknown [92.247.20.226]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 47B10564AE for ; Tue, 30 Sep 2014 07:22:47 +0000 (UTC) Message-ID: <542A5A45.4000708@freebsd.org> Date: Tue, 30 Sep 2014 03:22:45 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT References: <20140919201210.72650231.ohartman@zedat.fu-berlin.de> <20140920161012.02844320.ohartman@zedat.fu-berlin.de> <20140920191530.6b538c62.ohartman@zedat.fu-berlin.de> <20140920201347.0a4b9658.ohartman@zedat.fu-berlin.de> <1411240906.1174.2.camel@rainbow-runner.nl> <20140928114154.5f9c37cb.ohartman@zedat.fu-berlin.de> <5427DD70.5080906@gmail.com> <20140928130013.64cd74c9.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140928130013.64cd74c9.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 07:22:49 -0000 On 2014-09-28 07:00, O. Hartmann wrote: > Am Sun, 28 Sep 2014 12:05:36 +0200 > Jan Kokemüller schrieb: > >> > And as far as I know: even the Linuxulator is ways behind the recent development and > still 32Bit (ancient, so to speak). I do not want myself having lots of outdated hard- > and software running and developing on outdated platforms. > There is a working 64bit linuxulator in dchagin's project branch. Hopefully it will be merged into head soon, and we'll have full 64bit linux emulation for FreeBSD 11. -- Allan Jude From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 08:18:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD3E4DF9 for ; Tue, 30 Sep 2014 08:18:23 +0000 (UTC) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx12.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BA69EF9A for ; Tue, 30 Sep 2014 08:18:22 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.04,625,1406617200"; d="asc'?scan'208";a="200254714" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx12-out.netapp.com with ESMTP; 30 Sep 2014 01:18:08 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 30 Sep 2014 01:17:48 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::79b6:a9a2:f48b:f065%21]) with mapi id 15.00.0913.011; Tue, 30 Sep 2014 01:17:48 -0700 From: "Eggert, Lars" To: David Shane Holden Subject: Re: [PATCH] nscd Thread-Topic: [PATCH] nscd Thread-Index: AQHP3GBjNT+2UfEjw0qtQx963geD6pwZyrAA Date: Tue, 30 Sep 2014 08:17:47 +0000 Message-ID: <007A0492-5F92-44E8-8904-699F4A42C667@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1878.6) x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_BC6AF6C8-EBE8-4E30-8B94-062896192005"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 08:18:24 -0000 --Apple-Mail=_BC6AF6C8-EBE8-4E30-8B94-062896192005 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I've been seeing the same issues with nscd not caching, but = unfortunately your patch doesn't seem to change things, for better or = worse. My nsswitch.conf looks as follows: group: cache files nis hosts: cache files dns networks: cache files passwd: cache files nis shells: files services: cache files nis protocols: cache files rpc: cache files When I start "nscd -n -s -t" and then run top in another shell, top = takes ~10 seconds to start up every time; if nscd did its thing, repeat = invocations should be much faster. nscd doesn't seem to see any activity = either, based on its log: [elars@one: ~] sudo nscd -n -s -t M1 from main: request agents registered successfully M2 from cache: cache was successfully initialized M2 from runtime environment: using socket /var/run/nscd M2 from runtime environment: successfully initialized M1 from main: working in single-threaded mode Lars On 2014-9-30, at 5:40, David Shane Holden wrote: > So, I've noticed nscd hasn't worked right for awhile now. Since I > upgraded to 10.0 it never seemed to cache properly but I never = bothered > to really dig into it until recently and here's what I've found. In = my > environment I have nsswitch set to use caching and LDAP as such: >=20 > group: files cache ldap > passwd: files cache ldap >=20 > The LDAP part works fine, but caching didn't on 10.0 for some reason. > On my 9.2 machines it works as expected though. What I've found is in > usr.sbin/nscd/query.c >=20 > struct query_state * > init_query_state(int sockfd, size_t kevent_watermark, uid_t euid, = gid_t > egid) > { > ... > memcpy(&retval->timeout, &s_configuration->query_timeout, > sizeof(struct timeval)); > ... > } >=20 > s_configuration->query_timeout is an 'int' which is being memcpy'd = into > a 'struct timeval' causing it to grab other parts of the = s_configuration > struct along with the query_timeout value and polluting = retval->timeout. > In this case it appears to be grabbing s_configuration->threads_num = and > shoving that into timeout.tv_sec along with the query_timeout. This = ends > up confusing nscd later on (instead of being 8 it ends up being set to > 34359738376) and breaks it's ability to cache. I've attached a patch = to > set the retval->timeout properly and gets nscd working again. I'm > guessing gcc was handling this differently from clang which is why it > wasn't a problem before 10.0. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" --Apple-Mail=_BC6AF6C8-EBE8-4E30-8B94-062896192005 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVCpnONZcnpRveo1xAQLtXQP+Jg4yMI5XrHx+0nXX7wJEkcgiLYJP+frZ tiuvuLgJXLkfAY2IwDh6fe8wIH3BthPNbkCLx0lNW20QQU9UryNHhy1tYNaqX9+g 8c0a5KuUhTNM2yPsFPr6ektXcLXHhmvPTi9PaGOQ56MIN0D/z1lUTP+bxGH4K0iG zVxKZHKPe20= =NKgc -----END PGP SIGNATURE----- --Apple-Mail=_BC6AF6C8-EBE8-4E30-8B94-062896192005-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 14:44:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5200CF39 for ; Tue, 30 Sep 2014 14:44:17 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DF3468A for ; Tue, 30 Sep 2014 14:44:17 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j6jzM3FtNz1DP3 for ; Tue, 30 Sep 2014 10:44:15 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j6jzL4MBfz1Bms for ; Tue, 30 Sep 2014 10:44:14 -0400 (EDT) Message-ID: <201409301044110291.0060BD57@smtp.24cl.home> In-Reply-To: <20140929210142.M26034@beckpeccoz.com> References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409291603440911.019119CE@smtp.24cl.home> <20140929210142.M26034@beckpeccoz.com> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Tue, 30 Sep 2014 10:44:11 -0400 From: "Mike." To: freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:44:17 -0000 On 9/29/2014 at 11:04 PM Jos=C3=A9 P=C3=A9rez Arauzo wrote: |This encoded message has been converted to an attachment. | |Hi Mike, | |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote [...] |So that should put a time bracket on the issue, |roughly the first half of 2014. | |can you boot 271146? Just buildkernel and installkernel. Thank |you. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There doesn't seem to be much, if any, interest on the part of the FreeBSD developers in fixing this recently-introduced issue with booting up FreeBSD. Since I experience the problem only on the one notebook of mine, I'll just re-purpose that notebook for OpenBSD and try to find another old notebook that works with FreeBSD. Seems like the path of least resistance for me.... From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 14:47:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4DC8174 for ; Tue, 30 Sep 2014 14:47:47 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BBCE6D2 for ; Tue, 30 Sep 2014 14:47:47 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s8UEleqf067895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 Sep 2014 07:47:43 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <542AC286.8000903@freebsd.org> Date: Tue, 30 Sep 2014 22:47:34 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?Sm9zw6kgUMOpcmV6IEFyYXV6bw==?= , Garrett Cooper Subject: Re: What do you use for kernel debugging? References: <20140928071641.M7664@beckpeccoz.com> <761DF16E-5383-46BA-B886-CD3358D976AA@gmail.com> <20140929002025.M8991@aoek.com> In-Reply-To: <20140929002025.M8991@aoek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:47:48 -0000 On 9/29/14, 8:31 AM, José Pérez Arauzo wrote: > Hi Garrett, > > On Sun, 28 Sep 2014 13:38:24 -0700, Garrett Cooper wrote >> On Sep 28, 2014, at 0:34, José Pérez Arauzo wrote: >> >>> Hello, >>> I am trying to track down a (deadlock?) issue in CURRENT via DDB. The > kernel does >>> not complete hw probes on my Acer V5. >>> >>> I get stuck on apic_isr looping which leads nowhere. >>> >>> So I thought maybe things improve if I debug from another machine. >>> >>> >>> What do you use for kernel debugging? According to the handbook kgdb over > serial >>> is a good option, do you agree? I'm on a netbook with no ethernet and no > option >>> for firewire: can I have a USB / nullmodem setup to work? >>> >>> I have no old-style uarts hardware anymore, as the handbook suggests... >>> >>> Any idea is welcome before I buy extra hw. I have a USB to serial showing > up as >>> /dev/cuaU0, do I need to grab another one and a nullmodem cable or there > are better >>> alternatives? Thank you. >> There was some discussion recently about this on an internal list. >> Unfortunately no, there isn’t a usable way, but there were some >> interesting viable methods that came up (which haven’t been >> implemented): ethernet/sound/xHCI. >> >> Your best bet, as others have noted, is to use boot -d, use WITNESS >> to spot locking issues, dtrace to isolate which section of code >> there are problems, and finally use one of the DEBUG options noted >> in /sys/conf/NOTES and /sys//conf/NOTES . >> >> Hope that helps! > Well, it's not so encouraging but I'll work on it. > > Do you mean that we can get rid of chapter 10.5 of the handbook (On-Line > Kernel Debugging Using Remote GDB)? no it works when you have the hardware. but modern laptops have so little hardware.. we really will have to define an API/ABI to add to teh current ethernet driver API so that we can do network based debugging. it's getting harder and harder to find alternatives. (though debugging a VM works well). > Just to have it clear, when people develop or fix drivers in FreeBSD > their only option is to use the above mentioned tools, as they have no > access to a live, on-line kernel debugger?? It's disappointing, to say > the least! > > I hope Dcons + 1394 works where it's applicable. > > BR, > > -- > José Pérez Arauzo > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 14:53:47 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6681B5D6; Tue, 30 Sep 2014 14:53:47 +0000 (UTC) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2440780A; Tue, 30 Sep 2014 14:53:46 +0000 (UTC) Received: from um-excht-a01.um.gwdg.de ([134.76.11.221] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.80) (envelope-from ) id 1XYydk-0007iI-1O; Tue, 30 Sep 2014 16:42:56 +0200 Received: from krabat.raven.hur (84.186.202.246) by email.gwdg.de (134.76.9.210) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 30 Sep 2014 16:42:55 +0200 Message-ID: <542AC16B.5070202@gwdg.de> Date: Tue, 30 Sep 2014 16:42:51 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "O. Hartmann" , FreeBSD CURRENT , FreeBSD Ports Subject: Re: pkg/ports system terribly messed up? References: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Spam-Level: - X-Virus-Scanned: (clean) by clamav X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:53:47 -0000 Am 30.09.2014 um 08:13 schrieb O. Hartmann: > > Hello. > > I just made the last update of the ports yesterday (I use portmaster -da performing this > task) and obviously or superficially everything went all right. > > I'm running on the boxes in question most recent CURRENT. > > On one system, a subsequent start of updating ports starts to freak out when updateing > lang/gcc: it loops over and over on some ports already updated, especially > devel/binutils, but the port looping on isn't specific and varies. > > On every CURRENT box I tried this morning to update the ports again, I find this > frsutrating message (depends on installation, but it seems in principal the same, only > the affected ports in dependency chain varies): > > ===>>> Gathering distinfo list for installed ports > > ===>>> Starting check of installed ports for available updates > ===>>> Launching child to update openldap-sasl-client-2.4.39_2 to > openldap-sasl-client-2.4.40 > > ===>>> All >> openldap-sasl-client-2.4.39_2 (1/1) > > ===>>> Currently installed version: openldap-sasl-client-2.4.39_2 > ===>>> Port directory: /usr/ports/net/openldap24-sasl-client > > ===>>> Launching 'make checksum' for net/openldap24-sasl-client in background > ===>>> Gathering dependency list for net/openldap24-sasl-client from ports > ===>>> Launching child to install net/openldap24-sasl-client/../../ports-mgmt/pkg > > ===>>> All >> openldap-sasl-client-2.4.39_2 >> > net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2) > > ===>>> Port directory: /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg > > > ===>>> Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed > ===>>> Aborting update > > ===>>> Update for openldap-sasl-client-2.4.39_2 failed > ===>>> Aborting update > > You have new mail. > > > This isn't, so far, OpenLDAP specific, on other systems without LDAP the update fails on > another port. > > Oliver > I am afraid I am observing something similar to what Oliver reported. On a CURRENT box (r272295) I get the following for all ports execpt pkg itself: portmaster indexinfo-0.2 ===>>> Currently installed version: indexinfo-0.2 ===>>> Port directory: /usr/ports/print/indexinfo ===>>> Gathering distinfo list for installed ports ===>>> Launching 'make checksum' for print/indexinfo in background ===>>> Gathering dependency list for print/indexinfo from ports ===>>> Launching child to install print/indexinfo/../../ports-mgmt/pkg ===>>> indexinfo-0.2 >> print/indexinfo/../../ports-mgmt/pkg (1/1) ===>>> Port directory: /usr/ports/print/indexinfo/../../ports-mgmt/pkg ===>>> Update for print/indexinfo/../../ports-mgmt/pkg failed ===>>> Aborting update When I try to build other ports, it does not complain about ports-mgmt/pkg, but something else in the dependency list. For example, for net/mpich2 it complains about devel/binutils ... This does not happen on my other CURRENT boxes (they build ports as exected). All systems have pkg-1.3.8_2 installed. The main difference between these boxes is, that the boxes without problems come from older installations, which were converted via pkg2ng. Only the box in question has all ports built and installed from scratch after installing pkg, without any installations via pkg_* before. As far as I can say, all went well until r369572. After svn'ing to a more recent revision, I was not able to build ports any more ... HTH, Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 14:54:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0E54807 for ; Tue, 30 Sep 2014 14:54:26 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 008A382E for ; Tue, 30 Sep 2014 14:54:25 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s8UEiU02067885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 30 Sep 2014 07:44:33 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <542AC1C8.9030101@freebsd.org> Date: Tue, 30 Sep 2014 22:44:24 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Garrett Cooper , =?UTF-8?B?Sm9zw6kgUMOpcmV6IEFy?= =?UTF-8?B?YXV6bw==?= Subject: Re: What do you use for kernel debugging? References: <20140928071641.M7664@beckpeccoz.com> <20140929003358.M78145@aoek.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current , Benjamin Kaduk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:54:27 -0000 On 9/29/14, 9:35 AM, Garrett Cooper wrote: >> On Sep 28, 2014, at 17:51, "José Pérez Arauzo" wrote: >> >> Hi Benjamin, >> >> On Sun, 28 Sep 2014 15:54:36 -0400 (EDT), Benjamin Kaduk wrote >>> On Sun, 28 Sep 2014, José Pérez Arauzo wrote: >>> >>>> Hello, >>>> I am trying to track down a (deadlock?) issue in CURRENT via DDB. The >> kernel does >>>> not complete hw probes on my Acer V5. >>>> >>>> I get stuck on apic_isr looping which leads nowhere. >>>> >>>> So I thought maybe things improve if I debug from another machine. >>>> >>>> >>>> What do you use for kernel debugging? According to the handbook kgdb over >> serial >>>> is a good option, do you agree? I'm on a netbook with no ethernet and no >> option >>>> for firewire: can I have a USB / nullmodem setup to work? with hardware related debugging it's always hard.. in the past I used serial and firewire but they are getting hard to find. if it wasn't hardware related then using bhyve with it's gdb debugger hook works fine. Unfortunately you can't use a USB serial as it requires the USB stack be working before it can be used.. similar with ethernet connected debugging which requires that the driver for the ethernet hardware support it. (which why we don't have it in the tree though it has been done several times in the past). >>> You cannot. >> Oh, what a shame. Why not? Is it because you need hardware probe to >> be over to use it? >> >> Today I bought a shining USB to USB thingy made by Hama, and guess what? >> It's not supported on FBDS, altought uplcom(4) reports support for >> Hama USB to RS232 brother. > The bootloader doesn't support USB debugging and I'm pretty sure the devices don't support local/remote debugging :(.. I'll do some poking around. I'll talk to some SMEs and see if I can write up a TODO list for a wiki page. > > Cheers! > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 15:46:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41FE4272 for ; Tue, 30 Sep 2014 15:46:46 +0000 (UTC) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3D60E59 for ; Tue, 30 Sep 2014 15:46:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1412091839; bh=nQC9Prln2zTU62/ese7jcT/kShS9xTgaTR/I+mxVGl8=; h=Received:Received:Received:DKIM-Signature:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:From:Subject; b=rFqR5U+5pWKHr3sJy4+g8R7mQzuHuMs4V66WP83fOQtYxJg1Bt7Vaxet70HDFVQoZEfU82HOogRmzzdkiYMohKog00loSC3dWeQ7nVuYnzd3JkE6Y61tDPIIy9kCzzbQrA9CH1nIjSm76tXxfbauoHs6qO+62k2VNDbmAcvoBoacmHtQ9T8jp4bwams8+vD+BxGy1lDzeeanb7BVfHPY5ZjMu1Th6u4UGifdK0THCGEZOWj3nLbEpx2x9IS75lmi0ORUx4KWtODIgT6sp0stTTki7xTw/i8zQ3gGN7U2IdcTf6uGatg+774BWtdtC8SIPM4H2gpeGzLuKq1ahBmORg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=SmbepU/dP6atH3fyA9J24Bfu9e9gh6Fw/BO6Czvnn61EusaikjnlsFkv3i/2p8d0FFy9nfOg+EHOKxqiFymo/PPjZ2GDQtUieOZ5dpmRi1dfB2xq0cTOAWhm9GYqsUuhZdw4yZRrBombD+fS3cP106+a62mpCKMNJXUUEHCLYwld2+Wg80joTn5/DVsNCuE9icciQTTDH/L/7m9QuoGq3OznKYci+fCepPzoJ+PBBOR7uLb10PEDVrlfaVGTByUMRn7PwespT+5NzvOaTFLMlDTA62OLmyAweZdeRaSlpazOlFs+aoEk1ewCI+LZ48EG9x0kh53v2x0sC79tqGAplA==; Received: from [66.196.81.171] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 30 Sep 2014 15:43:59 -0000 Received: from [68.142.230.74] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 30 Sep 2014 15:43:59 -0000 Received: from [127.0.0.1] by smtp231.mail.bf1.yahoo.com with NNFMP; 30 Sep 2014 15:43:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1412091839; bh=nQC9Prln2zTU62/ese7jcT/kShS9xTgaTR/I+mxVGl8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lzGNGgIH2bm3b8T5VYiFoUe1uuhKyw4nQIISceQXZf96EMnuI/m+R+LsZJAybr3Xmnq5binyrflOwnji+EDQX7G0ZnDGj6o1Qt71qI2Y0V5JABYaRqPbfXwVnNukT/cez6vs62OOE58uAJ4QNX1RbR/Def39KxQ+2AyQtqO3fKM= X-Yahoo-Newman-Id: 651540.3725.bm@smtp231.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NfJYp9cVM1nvGxzsNZsl9UCMkG6O0kLUzd_KJBHRZl3RGTJ B.0BEEqaeRAcY1R0sVoo8f4530bUgMQ_ItfXIQe4pv0DciRGDzVkJ5VO1qKR HQDFGW3WcV1wB3MBQxHQzqQIR8pX9GHeIpDSR4XgVSVvrdfqXVir8M1H3MIZ 6Cx8_wBsP3yEY3T6VvpAMYHKGi36Cf3Na77_5lGvVebjE23xQxFA3UhItBZl .onOiAcvJlKexG_qz.NNjFy0XEcr_eM3AEpS7.9b8ROmMM.Clfplg4I77OGX UkRlhVDECpRuJUgtNBqWaLt6ABb1LNF5ef0SZv0SWFiThshqcrrHcbfXIj0v OSoDJ._lI7VT2w4SfzvKjjfU4mUinGWpvyFk4wBetRtcvKYxhq4mDkaV81Es bSShDtB9RWk.4EOauOxcU4Plc4wt34NnwpZRz2dAG1GazLxhQE7bIjXPzAAR raWK8TlSzT8ktTYzA2W1UQVDuHP3sTnJztH3X.S28AyBlR._9pSeYjkiRtx_ N2W_0nU9Y4IA0ZjLP8SEf X-Yahoo-SMTP: 4VhmBaWswBBKhhYsa0wE5OAFfRI- Message-ID: <542ACFBD.3000407@yahoo.com> Date: Tue, 30 Sep 2014 11:43:57 -0400 From: David Shane Holden User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: [PATCH] nscd References: <007A0492-5F92-44E8-8904-699F4A42C667@netapp.com> In-Reply-To: <007A0492-5F92-44E8-8904-699F4A42C667@netapp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:46:46 -0000 On 09/30/14 04:17, Eggert, Lars wrote: > When I start "nscd -n -s -t" and then run top in another shell, top > takes ~10 seconds to start up every time; if nscd did its thing, > repeat invocations should be much faster. nscd doesn't seem to see > any activity either, based on its log: The -t switch will only work after you change the #ifdef in debug.h to define the trace routines, and even then it doesn't give you too much information other than what methods are called. nscd could really use some debug logging but that's a whole other issue. As for why it's not working in your setup I can't say. Have you tried testing with getent to see which database is taking so long, and is that 10 seconds before or after the patch? By default nscd is suppose to timeout after 8 seconds so there might be something else going on in nscd which you're being affected by which is now being exposed. What I do know is when the timeout value is unusually large (in this case due to the bad memcpy) the kevent timer registered at the end of nscd.c:process_socket_event() doesn't seem to be honored. My guess is inside the kernel it's setting it to 0 if it exceeds some threshold so it immediately gets triggered. It's basically shooting itself in the head right when a connection to the socket is made. You can test this by running 'socat UNIX-CONNECT:/var/run/nscd -'. You'll notice that it instantly disconnects without the patch, then 8 seconds with it. From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 16:57:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C824E5E2 for ; Tue, 30 Sep 2014 16:57:23 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9296F95B for ; Tue, 30 Sep 2014 16:57:23 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id rl12so6939932iec.23 for ; Tue, 30 Sep 2014 09:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=+qfnbzDABSRBH39F3/3+dsru40VOzTtqGds+zPjH29Q=; b=QeBdiBM6zNIdnkoTIVKq5olpLALsE1mjFg1tkWrM+ZfeYgwrplaylJeFvhXY87JObO ItiNgWEZhuXoLoTFqaJ2DeRLuBuM3+8UKPNO0wCANGDPtWu3WFagtT9tPE5YVhSaPnVX 5tFNLkt/dU/Pf/zxGmMZe3Jtsi6IwUU0x/s61jJsKaGjXOkak9YTqq5km6eXHOiyQT8Q TOCdEdRuEFF+mh8+658OyLSK5WC3vuAiAKFwgG0EtgUOmE1JkZ0vlhUcoyY18C7MBmBO EOgWp5Rw8f1d5+RHteNJzYyE0Wim2NLojJHNQncxaPjPdWakoHWEa6VSLrf8KfFnMTqa zzvg== X-Received: by 10.42.117.65 with SMTP id s1mr8463105icq.97.1412096242976; Tue, 30 Sep 2014 09:57:22 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:31f6:564e:c031:22eb? ([2601:8:ab80:7d6:31f6:564e:c031:22eb]) by mx.google.com with ESMTPSA id dx10sm13496711igb.4.2014.09.30.09.57.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 09:57:21 -0700 (PDT) References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409291603440911.019119CE@smtp.24cl.home> <20140929210142.M26034@beckpeccoz.com> <201409301044110291.0060BD57@smtp.24cl.home> Mime-Version: 1.0 (1.0) In-Reply-To: <201409301044110291.0060BD57@smtp.24cl.home> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: Looping during boot-up process in FreeBSD-11 current Date: Tue, 30 Sep 2014 09:57:19 -0700 To: "Mike." Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 16:57:23 -0000 > On Sep 30, 2014, at 7:44, "Mike." wrote: >=20 > On 9/29/2014 at 11:04 PM Jos=C3=A9 P=C3=A9rez Arauzo wrote: >=20 > |This encoded message has been converted to an attachment. > | > |Hi Mike, > | > |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote > [...] > |So that should put a time bracket on the issue,=20 > |roughly the first half of 2014. > | > |can you boot 271146? Just buildkernel and installkernel. Thank > |you. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > There doesn't seem to be much, if any, interest on the part of the > FreeBSD developers in fixing this recently-introduced issue with > booting up FreeBSD. =20 >=20 > Since I experience the problem only on the one notebook of mine, I'll > just re-purpose that notebook for OpenBSD and try to find another old > notebook that works with FreeBSD. Seems like the path of least > resistance for me.... Did you boot with boot -d, using a stripped down kernel, and without SMP lik= e I suggested in another post? Thanks! -Garrett= From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 17:17:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED1B6255 for ; Tue, 30 Sep 2014 17:17:52 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8C73C43 for ; Tue, 30 Sep 2014 17:17:52 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j6nNZ5vGZz1DNt for ; Tue, 30 Sep 2014 13:17:50 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j6nNX70DRz1Bnd for ; Tue, 30 Sep 2014 13:17:48 -0400 (EDT) Message-ID: <201409301317450850.0015EB48@smtp.24cl.home> In-Reply-To: References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409291603440911.019119CE@smtp.24cl.home> <20140929210142.M26034@beckpeccoz.com> <201409301044110291.0060BD57@smtp.24cl.home> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Tue, 30 Sep 2014 13:17:45 -0400 From: "Mike." To: freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 17:17:53 -0000 On 9/30/2014 at 9:57 AM Garrett Cooper wrote: |Did you boot with boot -d, using a stripped down kernel, |and without SMP like I suggested in another post? ============= Unfortunately, this is the first message of yours that I've seen on this topic. I even checked the mailing list archives ( http://lists.freebsd.org/pipermail/freebsd-current/2014-September/auth or.html ) and I did not see any other message from you. Can you resend it? (I just tried boot -d and found myself in strange territory, a debugger?) thx. From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 17:25:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69A3E56A for ; Tue, 30 Sep 2014 17:25:18 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2ED2BD36 for ; Tue, 30 Sep 2014 17:25:16 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8UHPFTf027279; Tue, 30 Sep 2014 17:25:15 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: "Mike." , freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Date: Tue, 30 Sep 2014 19:25:10 +0200 Message-Id: <20140930171721.M83701@beckpeccoz.com> In-Reply-To: <201409301044110291.0060BD57@smtp.24cl.home> References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409291603440911.019119CE@smtp.24cl.home> <20140929210142.M26034@beckpeccoz.com> <201409301044110291.0060BD57@smtp.24cl.home> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 62.87.85.114 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 17:25:18 -0000 Hi Mike, On Tue, 30 Sep 2014 10:44:11 -0400, Mike. wrote > On 9/29/2014 at 11:04 PM José Pérez Arauzo wrote: > > |This encoded message has been converted to an attachment. > | > |Hi Mike, > | > |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote > [...] > |So that should put a time bracket on the issue, > |roughly the first half of 2014. > | > |can you boot 271146? Just buildkernel and installkernel. Thank > |you. > ============= > > There doesn't seem to be much, if any, interest on the part of the > FreeBSD developers in fixing this recently-introduced issue with > booting up FreeBSD. The glass is half full. Always. Did you get it to boot with 271146 as I suggested? This would really help and see if we are hitting the same issue or not. > Since I experience the problem only on the one notebook of mine, I'll > just re-purpose that notebook for OpenBSD and try to find another old > notebook that works with FreeBSD. Seems like the path of least > resistance for me.... C'mon, don't give up now. Try the 271146, I'm trying to find out where it exactly loops. I've done some testing and might be it'AHCI actually. Warner Losh (the maintainer) sent at least 3 messages about this, he's very cooperative I think. I'll try the no-SMP thing now just to see how it works. BR, -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 17:25:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB21E69E for ; Tue, 30 Sep 2014 17:25:59 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CE93D4D for ; Tue, 30 Sep 2014 17:25:59 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id fp1so5547010pdb.25 for ; Tue, 30 Sep 2014 10:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=xPpONa14cP2m94FemMVpeXue4tqlUD3WPZVyt08wZdM=; b=n9nRV7xl9udAjzb3tWZtZYay0gBRpTWCDPVwt6VpYqpu3Tz7hMUSgWxs16GgPm01wD pUNUX708I7XY0Exx2y5rT7tvAH0X/QEphD6DgvrbupVXRwzgnYiJ0S1FYXCpB77/e8EE IqtSarmD0xLpM0gSbNmaXc80l7RQTUzQCFMCVlZlgar3/6Ok2qDTLLxkro89Jxvrjybq 5dGrXKKDHGvA28GJVtL7ZaM4kDrgavRqVkF6br192eYKVeXsmKmUElv465Z8tBJyNX6X gA4BGrEa46kaQ1SAHA6w1ikBrXrA/0RIeHmEbNL9E30NxLJ5oIQceZ9kX/JNYZR8pBSa uYOA== X-Received: by 10.66.152.131 with SMTP id uy3mr67288539pab.29.1412097959011; Tue, 30 Sep 2014 10:25:59 -0700 (PDT) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id ds14sm15744229pdb.20.2014.09.30.10.25.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 10:25:57 -0700 (PDT) References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409291603440911.019119CE@smtp.24cl.home> <20140929210142.M26034@beckpeccoz.com> <201409301044110291.0060BD57@smtp.24cl.home> <201409301317450850.0015EB48@smtp.24cl.home> Mime-Version: 1.0 (1.0) In-Reply-To: <201409301317450850.0015EB48@smtp.24cl.home> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9CEE16D5-3F25-45A2-B2A2-5862F30FE3F1@gmail.com> X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: Looping during boot-up process in FreeBSD-11 current Date: Tue, 30 Sep 2014 10:25:55 -0700 To: "Mike." Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 17:25:59 -0000 > On Sep 30, 2014, at 10:17, "Mike." wrote: >=20 > On 9/30/2014 at 9:57 AM Garrett Cooper wrote: >=20 >=20 > |Did you boot with boot -d, using a stripped down kernel,=20 > |and without SMP like I suggested in another post? > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Unfortunately, this is the first message of yours that I've seen on > this topic. I even checked the mailing list archives > ( > http://lists.freebsd.org/pipermail/freebsd-current/2014-September/auth > or.html ) > and I did not see any other message from you. >=20 > Can you resend it? Look for the recent thread titled "what do you use for kernel debugging". It= sounds like both you an Jose have run into similar problems recently with m= obile hardware. > (I just tried boot -d and found myself in strange territory, a > debugger?) Ah, crud. I meant boot -v (verbose boot) -- sorry bout that :). Cheers! -Garrett PS I would help a bit if I still had netbook hardware and the time to help, b= ut I don't have the former and seem to be short on the latter recently.= From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 17:31:05 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D665B54 for ; Tue, 30 Sep 2014 17:31:05 +0000 (UTC) Received: from srv56-45.cdn.bestreaming.com (srv56-46.cdn.bestreaming.com [204.140.16.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D51D6E2B for ; Tue, 30 Sep 2014 17:31:04 +0000 (UTC) Received: from mail.yourbox.net (localhost [127.0.0.1]) by srv56-45.cdn.bestreaming.com (8.14.5/8.14.5) with ESMTP id s8UHV9ng027409; Tue, 30 Sep 2014 17:31:09 GMT (envelope-from fbl@aoek.com) From: "=?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauz?=o" To: Garrett Cooper , "Mike." Subject: Re: Looping during boot-up process in FreeBSD-11 current Date: Tue, 30 Sep 2014 19:31:03 +0200 Message-Id: <20140930172522.M83009@beckpeccoz.com> In-Reply-To: References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409291603440911.019119CE@smtp.24cl.home> <20140929210142.M26034@beckpeccoz.com> <201409301044110291.0060BD57@smtp.24cl.home> X-Mailer: OpenWebMail 2.53 X-OriginatingIP: 62.87.85.114 (ame) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 17:31:05 -0000 Hi Garrett, On Tue, 30 Sep 2014 09:57:19 -0700, Garrett Cooper wrote > > On Sep 30, 2014, at 7:44, "Mike." wrote: > > > > On 9/29/2014 at 11:04 PM José Pérez Arauzo wrote: > > > > |This encoded message has been converted to an attachment. > > | > > |Hi Mike, > > | > > |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote > > [...] > > |So that should put a time bracket on the issue, > > |roughly the first half of 2014. > > | > > |can you boot 271146? Just buildkernel and installkernel. Thank > > |you. > > ============= > > > > There doesn't seem to be much, if any, interest on the part of the > > FreeBSD developers in fixing this recently-introduced issue with > > booting up FreeBSD. > > > > Since I experience the problem only on the one notebook of mine, I'll > > just re-purpose that notebook for OpenBSD and try to find another old > > notebook that works with FreeBSD. Seems like the path of least > > resistance for me.... > > Did you boot with boot -d, using a stripped down kernel, and without > SMP like I suggested in another post? This suggestion was address to me, not Mike. :) I tried, as you suggested, I can reach vfs_mountroot if I don't include AHCI, so it must be that. Now I'm trying to take out SMP and add extra debugging things here and there. I'm not sure what I'm doing, but I do it anyway. In the worst case I'm learning something. Thank you for your suggestions! BR, -- José Pérez Arauzo From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 17:42:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A9C73EE for ; Tue, 30 Sep 2014 17:42:04 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BFF9F47 for ; Tue, 30 Sep 2014 17:42:04 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id fb1so8475672pad.39 for ; Tue, 30 Sep 2014 10:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=gCfBqSfHd/zJrIYYJXscJV4Y5zIZttvPTqqrAdYi5tc=; b=pFXtUrt/vYQrLMjlp9t5SxX8wjHMBAjCtJX0p9Kyf6KyqaXxAo+13qN0qmDLbz4sj2 WGmYbmR9zSw3E+L50cuD65Ab5MJkq06h5kb767EWxpQ0KGZshC1qEAifkOeIt7eLUxeH 8Z8duyEShspgPof3CtbRy5VwBrOANyOwtUZNgzdn2Z6V7SwPAuhs6BlhCS8wIiyPzaRO NXP3jGoJTvUGLufzrtdgvKF0yZOKQm5PkHDogHg/2TYo+FvanK7SrEEg+t2uH2dW/jXC VgJG5ZqEfXm1bvWvWULFijMK9/nXJlYMo8pbvVcKe0LPb5q2G00taTYiVSnoc/5o1WpJ RDOA== X-Received: by 10.70.95.229 with SMTP id dn5mr20174650pdb.4.1412098923587; Tue, 30 Sep 2014 10:42:03 -0700 (PDT) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id cw5sm15725481pbc.9.2014.09.30.10.42.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 10:42:01 -0700 (PDT) References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409291603440911.019119CE@smtp.24cl.home> <20140929210142.M26034@beckpeccoz.com> <201409301044110291.0060BD57@smtp.24cl.home> <20140930172522.M83009@beckpeccoz.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20140930172522.M83009@beckpeccoz.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <1BC56699-412E-428C-973B-B86076451362@gmail.com> X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: Looping during boot-up process in FreeBSD-11 current Date: Tue, 30 Sep 2014 10:41:59 -0700 To: =?utf-8?Q?Jos=C3=A9_P=C3=A9rez_Arauzo?= Cc: "Mike." , "freebsd-current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 17:42:04 -0000 > On Sep 30, 2014, at 10:31, "Jos=C3=A9 P=C3=A9rez Arauzo" wr= ote: >=20 > Hi Garrett, >=20 > On Tue, 30 Sep 2014 09:57:19 -0700, Garrett Cooper wrote >>> On Sep 30, 2014, at 7:44, "Mike." wrote: >>>=20 >>> On 9/29/2014 at 11:04 PM Jos=C3=A9 P=C3=A9rez Arauzo wrote: >>>=20 >>> |This encoded message has been converted to an attachment. >>> | >>> |Hi Mike, >>> | >>> |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote >>> [...] >>> |So that should put a time bracket on the issue,=20 >>> |roughly the first half of 2014. >>> | >>> |can you boot 271146? Just buildkernel and installkernel. Thank >>> |you. >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> There doesn't seem to be much, if any, interest on the part of the >>> FreeBSD developers in fixing this recently-introduced issue with >>> booting up FreeBSD. =20 >>>=20 >>> Since I experience the problem only on the one notebook of mine, I'll >>> just re-purpose that notebook for OpenBSD and try to find another old >>> notebook that works with FreeBSD. Seems like the path of least >>> resistance for me.... >>=20 >> Did you boot with boot -d, using a stripped down kernel, and without=20 >> SMP like I suggested in another post? >=20 > This suggestion was address to me, not Mike. :) >=20 > I tried, as you suggested, I can reach vfs_mountroot if I don't > include AHCI, so it must be that. >=20 > Now I'm trying to take out SMP and add extra debugging things here and > there. Another suggestion might be to compile the driver as a module or vice versa -= - what happens then? Why this is slightly more interesting sometimes is that compiling drivers in= to the kernel statically allows compilers to optimize out code, which may or= may not positively effect driver runtime (performance and functionality wis= e). It shouldn't affect driver load order though; that should be determinist= ic as long as the drivers and hardware (firmware and configuration) don't ch= ange. > I'm not sure what I'm doing, but I do it anyway. In the worst case I'm > learning something. >=20 > Thank you for your suggestions! NP!= From owner-freebsd-current@FreeBSD.ORG Tue Sep 30 22:02:52 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D60F13FB for ; Tue, 30 Sep 2014 22:02:52 +0000 (UTC) Received: from oneyou.mcmli.com (oneyou.mcmli.com [IPv6:2001:470:1d:8da::100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "oneyou.mcmli.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65E5AA8C for ; Tue, 30 Sep 2014 22:02:52 +0000 (UTC) Received: from sentry.24cl.com (unknown [IPv6:2001:558:6017:a2:a860:3073:4c46:6ac9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "sentry.24cl.com", Issuer "Mike's Certificate Authority" (verified OK)) by oneyou.mcmli.com (Postfix) with ESMTPS id 3j6vjP3LRLz1DN3 for ; Tue, 30 Sep 2014 18:02:49 -0400 (EDT) Received: from BigBloat (bigbloat.24cl.home [10.20.1.4]) by sentry.24cl.com (Postfix) with ESMTP id 3j6vjM71N7z1C4g for ; Tue, 30 Sep 2014 18:02:47 -0400 (EDT) Message-ID: <201409301802450173.011AD57C@smtp.24cl.home> In-Reply-To: <20140930171721.M83701@beckpeccoz.com> References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409291603440911.019119CE@smtp.24cl.home> <20140929210142.M26034@beckpeccoz.com> <201409301044110291.0060BD57@smtp.24cl.home> <20140930171721.M83701@beckpeccoz.com> X-Mailer: Courier 3.50.00.09.1098 (http://www.rosecitysoftware.com) (P) Date: Tue, 30 Sep 2014 18:02:45 -0400 From: "Mike." To: freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 22:02:52 -0000 On 9/30/2014 at 7:25 PM Jos=C3=A9 P=C3=A9rez Arauzo wrote: |[snip] |Try the 271146, |[snip] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I installed the 10.0 release CD. Then (after installing pkg, svn, etc.): cd /usr/src svn update -r271146 make buildkernel make installkernel reboot I got to the login prompt, so it did not exhibit the looping issue I've experienced. /usr/src/UPDATING shows 20140708 p7 as the latest patch for the source. dmesg (with boot -v) follows: (note: when I boot 11.0-current with boot -v, the looping begins right after the place where the "GEOM: new disk cd0" line appears in the dmesg below) Copyright (c) 1992-2014 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 10.0-RELEASE-p7 #0 r271146: Tue Sep 30 16:38:12 EDT 2014 root@a31pf:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Preloaded elf kernel "/boot/kernel/kernel" at 0xc1678000. Calibrating TSC clock ... TSC clock: 1698592154 Hz CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.59-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf24 Family =3D 0xf Model =3D 0x2 Stepping =3D 4 Features=3D0x3febf9ff Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size real memory =3D 1073741824 (1024 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001826000 - 0x000000003ee0efff, 1029607424 bytes (251369 pages) avail memory =3D 1029230592 (981 MB) XEN: CPU 0 has VCPU ID 4294967295 bios32: Found BIOS32 Service Directory header at 0xc00f7030 bios32: Entry =3D 0xfd7e0 (c00fd7e0) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xfd770+0x18e pnpbios: Found PnP BIOS data at 0xc00f7090 pnpbios: Entry =3D f0000:9d76 Rev =3D 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: ULE: setup cpu 0 wlan: <802.11 Link Layer> snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [1024] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 Hardware, VIA Nehemiah Padlock RNG: VIA Padlock RNG not present Hardware, Intel IvyBridge+ RNG: RDRAND is not present kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled nfslock: pseudo-device null: Falling back to random adaptor random: initialized VESA: INT 0x10 vector 0xc000:0x206c VESA: information block 0000 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 0010 00 01 ff 03 00 01 19 01 00 01 2f 01 00 01 34 01 0020 00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 0030 94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 0040 b2 01 b3 01 b4 01 b5 01 b6 01 c2 01 c3 01 c4 01 0050 c5 01 c6 01 00 01 83 01 84 01 85 01 86 01 01 01 0060 10 01 11 01 12 01 21 01 03 01 13 01 14 01 15 01 0070 22 01 05 01 16 01 17 01 18 01 23 01 07 01 19 01 0080 1a 01 1b 01 24 01 40 01 41 01 42 01 43 01 44 01 0090 72 01 73 01 74 01 75 01 76 01 ff ff 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 41 54 49 20 4d 4f 42 49 4c 49 54 59 20 52 41 44 0110 45 4f 4e 20 37 35 30 30 00 41 54 49 20 54 65 63 0120 68 6e 6f 6c 6f 67 69 65 73 20 49 6e 63 2e 00 50 0130 37 20 20 00 30 31 2e 30 30 00 00 00 00 00 00 00 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 60 mode(s) found VESA: v2.0, 65472k memory, flags:0x1, mode table:0xe3ee6022 (1000022) VESA: ATI MOBILITY RADEON 7500 VESA: ATI Technologies Inc. P7 01.00 io: hpt27xx: RocketRAID 27xx controller driver v1.1 hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 hptnr: R750/DC7280 controller driver v1.0 ACPI: RSDP 0xf7060 00024 (v02 IBM ) ACPI: XSDT 0x3ff72c6d 00044 (v01 IBM TP-1G 00001120 LTP 00000000) ACPI: FACP 0x3ff72d00 00081 (v01 IBM TP-1G 00001120 IBM 00000001) ACPI: DSDT 0x3ff72de7 0B06F (v01 IBM TP-1G 00001120 MSFT 0100000D) ACPI: FACS 0x3ff7f000 00040 ACPI: SSDT 0x3ff72db4 00033 (v01 IBM TP-1G 00001120 MSFT 0100000D) ACPI: ECDT 0x3ff7de56 00052 (v01 IBM TP-1G 00001120 IBM 00000001) ACPI: BOOT 0x3ff7dfd8 00028 (v01 IBM TP-1G 00001120 LTP 00000001) acpi0: on motherboard ACPI: All ACPI Tables successfully acquired acpi_ec0: port 0x62,0x66 on acpi0 pci_open(1): mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D1a308086) pcibios: BIOS version 2.10 acpi0: Power Button (fixed) acpi0: wakeup code va 0xe3f17000 pa 0x1000 atpic: Programming IRQ9 as level/low acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3ff00000 (3) failed cpu0: on acpi0 cpu0: switching to generic Cx mode attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) Event timer "RTC" frequency 32768 Hz quality 0 ACPI timer: 0/15 0/15 0/15 0/15 0/15 0/15 0/15 0/15 0/15 0/15 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 Validation 0 255 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 Validation 0 255 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 Validation 0 255 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: decoding 4 range 0-0xcf7 pcib0: decoding 4 range 0xd00-0xffff pcib0: decoding 3 range 0xa0000-0xbffff pcib0: decoding 3 range 0xd4000-0xd7fff pcib0: decoding 3 range 0xd8000-0xdbfff pcib0: decoding 3 range 0x40000000-0xfebfffff ACPI: Found matching pin for 0.29.INTA at func 0: 11 ACPI: Found matching pin for 0.29.INTB at func 1: 11 ACPI: Found matching pin for 0.29.INTC at func 2: 11 ACPI: Found matching pin for 0.31.INTA at func 1: 255 ACPI: Found matching pin for 0.31.INTB at func 3: 11 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x1a30, revid=3D0x04 domain=3D0, 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) map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 26, enabled pcib0: allocated type 3 (0xe0000000-0xe3ffffff) for rid 10 of pci0:0:0:0 found-> vendor=3D0x8086, dev=3D0x1a31, revid=3D0x04 domain=3D0, bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x00a0, cachelnsz=3D0 (dwords) lattimer=3D0x60 (2880 ns), mingnt=3D0x0c (3000 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x2482, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 map[20]: type I/O Port, range 32, base 0x1800, size 5, enabled pcib0: allocated type 4 (0x1800-0x181f) for rid 20 of pci0:0:29:0 pcib0: matched entry for 0.29.INTA (src \134_SB_.LNKA:0) pcib0: slot 29 INTA routed to irq 11 via \134_SB_.LNKA found-> vendor=3D0x8086, dev=3D0x2484, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: allocated type 4 (0x1820-0x183f) for rid 20 of pci0:0:29:1 pcib0: matched entry for 0.29.INTB (src \134_SB_.LNKD:0) pcib0: slot 29 INTB routed to irq 11 via \134_SB_.LNKD found-> vendor=3D0x8086, dev=3D0x2487, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D2 class=3D0c-03-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=3Dc, irq=3D11 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: allocated type 4 (0x1840-0x185f) for rid 20 of pci0:0:29:2 pcib0: matched entry for 0.29.INTC (src \134_SB_.LNKC:0) pcib0: slot 29 INTC routed to irq 11 via \134_SB_.LNKC found-> vendor=3D0x8086, dev=3D0x2448, revid=3D0x42 domain=3D0, bus=3D0, slot=3D30, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0080, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x248c, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x000f, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x248a, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:31:1 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:31:1 pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:31:1 pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:31:1 map[20]: type I/O Port, range 32, base 0x1860, size 4, enabled pcib0: allocated type 4 (0x1860-0x186f) for rid 20 of pci0:0:31:1 map[24]: type Memory, range 32, base 0, size 10, memory disabled found-> vendor=3D0x8086, dev=3D0x2483, revid=3D0x02 domain=3D0, 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=3D11 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: allocated type 4 (0x1880-0x189f) for rid 20 of pci0:0:31:3 pcib0: matched entry for 0.31.INTB (src \134_SB_.LNKB:0) pcib0: slot 31 INTB routed to irq 11 via \134_SB_.LNKB found-> vendor=3D0x8086, dev=3D0x2485, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D5 class=3D04-01-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[10]: type I/O Port, range 32, base 0x1c00, size 8, enabled pcib0: allocated type 4 (0x1c00-0x1cff) for rid 10 of pci0:0:31:5 map[14]: type I/O Port, range 32, base 0x18c0, size 6, enabled pcib0: allocated type 4 (0x18c0-0x18ff) for rid 14 of pci0:0:31:5 pcib0: matched entry for 0.31.INTB (src \134_SB_.LNKB:0) pcib0: slot 31 INTB routed to irq 11 via \134_SB_.LNKB found-> vendor=3D0x8086, dev=3D0x2486, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D6 class=3D07-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[10]: type I/O Port, range 32, base 0x2400, size 8, enabled pcib0: allocated type 4 (0x2400-0x24ff) for rid 10 of pci0:0:31:6 map[14]: type I/O Port, range 32, base 0x2000, size 7, enabled pcib0: allocated type 4 (0x2000-0x207f) for rid 14 of pci0:0:31:6 pcib0: matched entry for 0.31.INTB (src \134_SB_.LNKB:0) pcib0: slot 31 INTB routed to irq 11 via \134_SB_.LNKB agp0: on hostb0 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: allocating non-ISA range 0x3000-0x30ff pcib0: allocated type 4 (0x3000-0x30ff) for rid 1c of pcib1 pcib1: allocating non-ISA range 0x3400-0x34ff pcib0: allocated type 4 (0x3400-0x34ff) for rid 1c of pcib1 pcib1: allocating non-ISA range 0x3800-0x38ff pcib0: allocated type 4 (0x3800-0x38ff) for rid 1c of pcib1 pcib1: allocating non-ISA range 0x3c00-0x3cff pcib0: allocated type 4 (0x3c00-0x3cff) for rid 1c of pcib1 pcib0: allocated type 3 (0xd0100000-0xd01fffff) for rid 20 of pcib1 pcib0: allocated type 3 (0xe8000000-0xefffffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x3000-0x3fff pcib1: memory decode 0xd0100000-0xd01fffff pcib1: prefetched decode 0xe8000000-0xefffffff pcib1: special decode ISA, VGA ACPI: Found matching pin for 1.0.INTA at func 0: 11 pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 found-> vendor=3D0x1002, dev=3D0x4c58, revid=3D0x00 domain=3D0, bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0387, statreg=3D0x02b0, cachelnsz=3D8 (dwords) lattimer=3D0x42 (1980 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe8000000, size 27, enabled pcib1: allocated prefetch range (0xe8000000-0xefffffff) for rid 10 of pci0:1:0:0 map[14]: type I/O Port, range 32, base 0x3000, size 8, enabled pcib1: allocated I/O port range (0x3000-0x30ff) for rid 14 of pci0:1:0:0 map[18]: type Memory, range 32, base 0xd0100000, size 16, enabled pcib1: allocated memory range (0xd0100000-0xd010ffff) for rid 18 of pci0:1:0:0 pcib1: matched entry for 1.0.INTA (src \134_SB_.LNKA:0) pcib1: slot 0 INTA routed to irq 11 via \134_SB_.LNKA vgapci0: port 0x3000-0x30ff mem 0xe8000000-0xefffffff,0xd0100000-0xd010ffff irq 11 at device 0.0 on pci1 vgapci0: Boot video device uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 usbus0 on uhci0 uhci0: usbpf: Attached uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 usbus1 on uhci1 uhci1: usbpf: Attached uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 usbus2 on uhci2 uhci2: usbpf: Attached pcib2: at device 30.0 on pci0 pcib2: allocating non-ISA range 0x4000-0x40ff pcib0: allocated type 4 (0x4000-0x40ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x4400-0x44ff pcib0: allocated type 4 (0x4400-0x44ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x4800-0x48ff pcib0: allocated type 4 (0x4800-0x48ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x4c00-0x4cff pcib0: allocated type 4 (0x4c00-0x4cff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x5000-0x50ff pcib0: allocated type 4 (0x5000-0x50ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x5400-0x54ff pcib0: allocated type 4 (0x5400-0x54ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x5800-0x58ff pcib0: allocated type 4 (0x5800-0x58ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x5c00-0x5cff pcib0: allocated type 4 (0x5c00-0x5cff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x6000-0x60ff pcib0: allocated type 4 (0x6000-0x60ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x6400-0x64ff pcib0: allocated type 4 (0x6400-0x64ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x6800-0x68ff pcib0: allocated type 4 (0x6800-0x68ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x6c00-0x6cff pcib0: allocated type 4 (0x6c00-0x6cff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x7000-0x70ff pcib0: allocated type 4 (0x7000-0x70ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x7400-0x74ff pcib0: allocated type 4 (0x7400-0x74ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x7800-0x78ff pcib0: allocated type 4 (0x7800-0x78ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x7c00-0x7cff pcib0: allocated type 4 (0x7c00-0x7cff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x8000-0x80ff pcib0: allocated type 4 (0x8000-0x80ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x8400-0x84ff pcib0: allocated type 4 (0x8400-0x84ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x8800-0x88ff pcib0: allocated type 4 (0x8800-0x88ff) for rid 1c of pcib2 pcib2: allocating non-ISA range 0x8c00-0x8cff pcib0: allocated type 4 (0x8c00-0x8cff) for rid 1c of pcib2 pcib0: allocated type 3 (0xd0200000-0xdfffffff) for rid 20 of pcib2 pcib0: allocated type 3 (0xf0000000-0xf7ffffff) for rid 24 of pcib2 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 8 pcib2: I/O decode 0x4000-0x8fff pcib2: memory decode 0xd0200000-0xdfffffff pcib2: prefetched decode 0xf0000000-0xf7ffffff pcib2: special decode ISA, subtractive ACPI: Found matching pin for 2.0.INTA at func 0: 11 ACPI: Found matching pin for 2.0.INTB at func 1: 11 ACPI: Found matching pin for 2.0.INTC at func 2: 11 ACPI: Found matching pin for 2.8.INTA at func 0: 11 pci2: on pcib2 pci2: domain=3D0, physical bus=3D2 found-> vendor=3D0x1180, dev=3D0x0476, revid=3D0xa8 domain=3D0, bus=3D2, slot=3D0, func=3D0 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x80 (32000 ns), maxlat=3D0x07 (1750 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x50000000, size 12, enabled pcib0: allocated type 3 (0x50000000-0x50000fff) for rid 10 of pci0:2:0:0 pcib2: matched entry for 2.0.INTA (src \134_SB_.LNKA:0) pcib2: slot 0 INTA routed to irq 11 via \134_SB_.LNKA found-> vendor=3D0x1180, dev=3D0x0476, revid=3D0xa8 domain=3D0, bus=3D2, slot=3D0, func=3D1 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x80 (32000 ns), maxlat=3D0x07 (1750 ns) intpin=3Db, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0x50100000, size 12, enabled pcib0: allocated type 3 (0x50100000-0x50100fff) for rid 10 of pci0:2:0:1 pcib2: matched entry for 2.0.INTB (src \134_SB_.LNKB:0) pcib2: slot 0 INTB routed to irq 11 via \134_SB_.LNKB found-> vendor=3D0x1180, dev=3D0x0552, revid=3D0x00 domain=3D0, bus=3D2, slot=3D0, func=3D2 class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0106, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x02 (500 ns), maxlat=3D0x04 (1000 ns) intpin=3Dc, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd0201000, size 11, enabled pcib2: allocated memory range (0xd0201000-0xd02017ff) for rid 10 of pci0:2:0:2 pcib2: matched entry for 2.0.INTC (src \134_SB_.LNKC:0) pcib2: slot 0 INTC routed to irq 11 via \134_SB_.LNKC found-> vendor=3D0x8086, dev=3D0x1031, revid=3D0x42 domain=3D0, bus=3D2, slot=3D8, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x0290, cachelnsz=3D8 (dwords) lattimer=3D0x42 (1980 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x38 (14000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xd0200000, size 12, enabled pcib2: allocated memory range (0xd0200000-0xd0200fff) for rid 10 of pci0:2:8:0 map[14]: type I/O Port, range 32, base 0x8000, size 6, enabled pcib2: allocated I/O port range (0x8000-0x803f) for rid 14 of pci0:2:8:0 pcib2: matched entry for 2.8.INTA (src \134_SB_.LNKE:0) pcib2: slot 8 INTA routed to irq 11 via \134_SB_.LNKE cbb0: mem 0x50000000-0x50000fff irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: PCI Configuration space: 0x00: 0x04761180 0x02100107 0x060700a8 0x00824000 0x10: 0x50000000 0x020000dc 0xb0050302 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0700010b 0x40: 0x01851014 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x04800001 0x00000000 0x04630464 0x00000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x008a0000 0x00000000 0x00f00000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x01851014 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0xfe0a0001 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: mem 0x50100000-0x50100fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: PCI Configuration space: 0x00: 0x04761180 0x02100107 0x060700a8 0x00824000 0x10: 0x50100000 0x020000dc 0xb0080602 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0700020b 0x40: 0x01851014 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x04800001 0x00000000 0x04630464 0x00000000 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 0xa0: 0x008a0000 0x00000000 0x00f00000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x01851014 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0xfe0a0001 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 pci2: at device 0.2 (no driver attached) fxp0: port 0x8000-0x803f mem 0xd0200000-0xd0200fff irq 11 at device 8.0 on pci2 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1031 1014 0209 0042 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: OUI 0x005500, model 0x0033, rev. 0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow fxp0: bpf attached fxp0: Ethernet address: 00:0e:9b:2c:c7:f6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff irq 11 at device 31.5 on pci0 pcm0: pcm0: Codec features headphone, 6 bit master volume, Analog Devices Phat Stereo pcm0: Primary codec extended features variable rate PCM pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "speaker": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: Mixer "video": pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: fast interrupt ppc0: using extended I/O port range battery0: on acpi0 acpi_acad0: on acpi0 ex_isa_identify() ahc_isa_identify 0: ioport 0xc00 alloc failed ahc_isa_identify 1: ioport 0x1c00 alloc failed ahc_isa_identify 2: ioport 0x2c00 alloc failed ahc_isa_identify 3: ioport 0x3c00 alloc failed ahc_isa_identify 4: ioport 0x4c00 alloc failed ahc_isa_identify 5: ioport 0x5c00 alloc failed ahc_isa_identify 6: ioport 0x6c00 alloc failed ahc_isa_identify 7: ioport 0x7c00 alloc failed ahc_isa_identify 8: ioport 0x8c00 alloc failed ahc_isa_identify 9: ioport 0x9c00 alloc failed ahc_isa_identify 10: ioport 0xac00 alloc failed ahc_isa_identify 11: ioport 0xbc00 alloc failed ahc_isa_identify 12: ioport 0xcc00 alloc failed ahc_isa_identify 13: ioport 0xdc00 alloc failed ahc_isa_identify 14: ioport 0xec00 alloc failed 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 pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 3 of orm0 pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 3 of orm0 pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 3 of orm0 pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 3 of orm0 pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 3 of orm0 pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 3 of orm0 pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 3 of orm0 pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 3 of orm0 pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 3 of orm0 pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 3 of orm0 pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 3 of orm0 pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 3 of orm0 pcib0: allocated type 3 (0xda000-0xda7ff) for rid 3 of orm0 pcib0: allocated type 3 (0xda800-0xdafff) for rid 3 of orm0 pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 3 of orm0 pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 3 of orm0 isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe000 0-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: parallel port not found. ppc0 failed to probe at irq 7 on isa0 uart1 failed to probe at port 0x2f8 irq 3 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices acpi_perf0: on cpu0 p4tcc0: on cpu0 Device configuration finished. procfs registered Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining tcp_init: net.inet.tcp.tcbhashsize auto tuned to 8192 lo0: bpf attached hpt27xx: no controller detected. hptrr: no controller detected. hptnr: no controller detected. pcm0: measured ac97 link rate at 48003 Hz, will use 48000 Hz random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ugen2.1: at usbus2 uhub0: on usbus2 ugen1.1: at usbus1 uhub1: on usbus1 ugen0.1: at usbus0 uhub2: on usbus0 ata1: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata1: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x30000 battery0: battery initialization start acpi_acad0: acline initialization start battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ata1: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata1: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x30000 (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata1:0:1:0): CAM status: Command timeout (aprobe0:ata1:0:1:0): Error 5, Retry was blocked run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ata1: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata1: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: stat1=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x30000 (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00 (aprobe0:ata1:0:1:0): CAM status: Command timeout (aprobe0:ata1:0:1:0): Error 5, Retry was blocked ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-6 device ada0: Serial Number MPC412Y4G6J1AE ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) GEOM: new disk ada0 ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 pass0 at ata0 bus 0 scbus0 target 0 lun 0 pass0: ATA-6 device pass0: Serial Number MPC412Y4G6J1AE pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass1 at ata1 bus 0 scbus1 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [288727 x 2048 byte records] TSC timecounter disabled: C3 enabled. Timecounter "TSC" frequency 1698592154 Hz quality -1000 GEOM: new disk cd0 Trying to mount root from ufs:/dev/ada0p2 [rw]... start_init: trying /sbin/init - fini - From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 01:36:46 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9AB8178 for ; Wed, 1 Oct 2014 01:36:46 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E64B21A for ; Wed, 1 Oct 2014 01:36:46 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id fp1so107265pdb.39 for ; Tue, 30 Sep 2014 18:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=PonDdlV6bR+77akAuSt21R93yHkj/p539NcD9F5klQs=; b=A2b15fcdXsKhg4qimfaj/z+WcSDMQhGSB0BPucztWSkdFmqCv2u2I8JbBsWIUD9xUO RKk0gxHuR+VkAhzOT+xwRFUkWQAhbOhkuDeWBs9VdilOSG3MCjZg9hqN0+WKgZirGWTa IMVaIhmBTIEbsHBGhLlvp7Lm9ISrYqaIj4NbIyOXXhqwsvqswt9+5FZDL1ta1dcxtLq/ leZcuDib/FKlj7Qx6W8o77bq5FvSlcw1aGnY5GTY6PFweLlItpeUGobLanIm3DRVd5EI YH3JGTdjYxUAuJ0NCRcejN5TE3kvUmt8snwWF0JG7OHDv8qWvP2y8/UHLvd1rg7NKIDz v0EA== X-Received: by 10.66.162.40 with SMTP id xx8mr74648082pab.31.1412127406197; Tue, 30 Sep 2014 18:36:46 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id bv5sm16281471pbc.20.2014.09.30.18.36.42 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Sep 2014 18:36:45 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 01 Oct 2014 10:36:37 +0900 Date: Wed, 1 Oct 2014 10:36:37 +0900 To: freebsd-current@freebsd.org Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support Message-ID: <20141001013637.GD2632@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <20140930015741.GA2451@michelle.fasterthan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140930015741.GA2451@michelle.fasterthan.com> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 01:36:46 -0000 On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote: > Hi, > I've added support for QAC AR816x/AR817x ethernet controllers. It > passed my limited testing and I need more testers. You can find > patches from the following URLs. > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff > and > http://people.freebsd.org/~yongari/alc/alc.diff.20140930 > > pci.qurik.diff is to workaround silicon bug of AR816x. Without it > MSI/MSIX interrupt wouldn't work. If you just want to use > legacy INTx interrupt you don't have to apply it but you have to > tell alc(4) not to use MSI/MSIX interrupt with tunables( > hw.alc.msi.disable and hw.alc.msix_disable). > > alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172 > and E2200 controllers. It supports all hardware features except > RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x > controllers please test and report how the diff works for you. > Thanks. http://people.freebsd.org/~yongari/alc/pci.quirk.diff http://people.freebsd.org/~yongari/alc/alc.diff.20141001 Patch updated to address link establishment issue. From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 03:44:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3ADCFC86 for ; Wed, 1 Oct 2014 03:44:35 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE557167 for ; Wed, 1 Oct 2014 03:44:34 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id w8so208842qac.19 for ; Tue, 30 Sep 2014 20:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:content-type; bh=wEPMpuAz2WgvrGWzs9xgfmVxU8DeOtGcmpTnYX7wWVU=; b=doBQoTAGCUJuV82dTDT4mRC3orRF1PklZXhQu0anKznKkOjZM1ksikxNYTT+hs/DEq 3KbSExp86Qgu4dZlcKv0g7ymh4GmRtmCIJXCwRwQnIdYSJ+Fc1RLGpCAFQJmRXGhECJ5 w8Nplvh7W9MwNFIKCONAmalp0s1GsUNsT5dMJA8XDO6AzdGvJ7gjBM5QTVJoVy8MHbtf o1jdacf8aoHQi+wH3dQCaa5ft3t+9q/Wb6IZ/7Ns/gi6zEDJI+jcaXzVYNdRThWCbpVE qcnftRtsKmyCeIMQaGQq+aoBzdK1VvYRqRyb0hq+LqFXuFd1hKea/X3gJMFOXqX+Q+Hd ZplQ== X-Received: by 10.224.120.193 with SMTP id e1mr26353884qar.80.1412135074042; Tue, 30 Sep 2014 20:44:34 -0700 (PDT) Received: from blackbeast.localnet (173-26-254-198.client.mchsi.com. [173.26.254.198]) by mx.google.com with ESMTPSA id j52sm15455256qgf.7.2014.09.30.20.44.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Sep 2014 20:44:33 -0700 (PDT) From: Chuck Burns To: freebsd-current@freebsd.org Subject: Re: pkg/ports system terribly messed up? Date: Tue, 30 Sep 2014 22:44:53 -0500 Message-ID: <4180223.sAzr7DGzUz@blackbeast> User-Agent: KMail/4.13.3 (Linux/3.10.17; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> References: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 03:44:35 -0000 On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote: > Hello. > > I just made the last update of the ports yesterday (I use portmaster -da > performing this task) and obviously or superficially everything went all > right. > It's portmaster actually. While it -usually- works great, I've noticed that occassionally it loops like that. kill the script, upgrade the port that is looping. That usually fixes it. -- Chuck Burns From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 04:46:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8687DA5; Wed, 1 Oct 2014 04:46:10 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd51.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74FBB8F6; Wed, 1 Oct 2014 04:46:09 +0000 (UTC) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s914jqV7029176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 00:45:54 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s914jqV7029176 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1412138754; bh=6R3iJ64XIxvqLoD1rLf35/11cww=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=hI189R5zkyvyQ3sCp0XauTLqQbjaMa8W17SW6Clso7U947+mYA1WZg51dQ6tFjsdG pPdkaHkVCSzUYJ0QkX1QPmg/pNPYtaMu0al0C/9alzWBiTxwMY3pIY5eR/yFu04GvX x+jZnVDZGdJ69CPl0FGQDYARbT4eMBdVDWaeYZco= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s914jqV7029176 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 1 Oct 2014 00:45:28 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s914jdAv010365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 00:45:39 -0400 Received: from mx34a.corp.emc.com ([169.254.1.46]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Wed, 1 Oct 2014 00:45:39 -0400 From: "O'Connor, Daniel" To: Julian Elischer Date: Wed, 1 Oct 2014 00:45:10 -0400 Subject: Re: What do you use for kernel debugging? Thread-Topic: What do you use for kernel debugging? Thread-Index: Ac/dMox5TpZy4R3cSbuYRe6Vn87ciQ== Message-ID: <90CE0701-F1CB-41DF-B3D2-87816DC03DF9@emc.com> References: <20140928071641.M7664@beckpeccoz.com> <20140929003358.M78145@aoek.com> <542AC1C8.9030101@freebsd.org> In-Reply-To: <542AC1C8.9030101@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Wed, 01 Oct 2014 04:56:06 +0000 Cc: =?Windows-1252?Q?Jos=E9_P=E9rez_Arauzo?= , FreeBSD Current , Benjamin Kaduk , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 04:46:10 -0000 On 1 Oct 2014, at 0:14, Julian Elischer wrote: > Unfortunately you can't use a USB serial as it requires the USB stack=20 > be working before it can be used.. > similar with ethernet connected debugging which requires that the=20 > driver for the ethernet hardware support it. > (which why we don't have it in the tree though it has been done=20 > several times in the past). There IS a USB debug standard, Linux has some code to support it. I am not sure what percentage of hardware has it hooked up though (the host= controller has a designated debug port but it could physically be anything= ). http://www.coreboot.org/EHCI_Debug_Port The hardware is bit more expensive than a null modem or firewire cable thou= gh :( Regards, Daniel O=92Connor Senior Software Engineer Isilon Platforms Team From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 05:03:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5ED09599; Wed, 1 Oct 2014 05:03:12 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C440FEAA; Wed, 1 Oct 2014 05:03:11 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id a1so106356wgh.21 for ; Tue, 30 Sep 2014 22:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=nv4bFdCQVlZlAATW7s/iBxA3JdRg54mWETU7xJaES30=; b=eHGdSBIQQ0uxpQrOZ9pg1WwCHy4T/Nk9M6D1Jz3dCywzPYnMrMi19taGNutIB2uIuk UhPBIfTgARmXBX/ZErn8kQgYn4CqEBviUcmfLxQLUKCOtckSsTbxH5r/olX7fw/ThPJU nvXhLeAGofZeI7jvene9NgBjdznvEpKKDG3K1hkCSQFtZQD9bMANiMwYVw5fIHVr4XCi tGguJ/tZ5Klr1z62WECRvnH+oHyPab9eQhSZtyRJjc16bj20E1QKJTk8jIi3qHFZc9+W tL1zonULH+CTX8jkLAWS4obwapOe8W6fVaN+x4iBxPK1SmCG5nmE5y6bXJw3aMnQ4LgB bFlQ== MIME-Version: 1.0 X-Received: by 10.194.157.230 with SMTP id wp6mr41686550wjb.15.1412139790034; Tue, 30 Sep 2014 22:03:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Tue, 30 Sep 2014 22:03:09 -0700 (PDT) In-Reply-To: <90CE0701-F1CB-41DF-B3D2-87816DC03DF9@emc.com> References: <20140928071641.M7664@beckpeccoz.com> <20140929003358.M78145@aoek.com> <542AC1C8.9030101@freebsd.org> <90CE0701-F1CB-41DF-B3D2-87816DC03DF9@emc.com> Date: Tue, 30 Sep 2014 22:03:09 -0700 X-Google-Sender-Auth: 1mCd-iHuRQbINIzp6QxthuwsiS4 Message-ID: Subject: Re: What do you use for kernel debugging? From: Adrian Chadd To: "O'Connor, Daniel" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauzo?= , FreeBSD Current , Benjamin Kaduk , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 05:03:12 -0000 There's also something for XHCI. Please please write it for freebsd. :) -a On 30 September 2014 21:45, O'Connor, Daniel wrot= e: > > On 1 Oct 2014, at 0:14, Julian Elischer wrote: >> Unfortunately you can't use a USB serial as it requires the USB stack >> be working before it can be used.. >> similar with ethernet connected debugging which requires that the >> driver for the ethernet hardware support it. >> (which why we don't have it in the tree though it has been done >> several times in the past). > > There IS a USB debug standard, Linux has some code to support it. > > I am not sure what percentage of hardware has it hooked up though (the ho= st controller has a designated debug port but it could physically be anythi= ng). > > http://www.coreboot.org/EHCI_Debug_Port > > The hardware is bit more expensive than a null modem or firewire cable th= ough :( > > Regards, > Daniel O=E2=80=99Connor > > Senior Software Engineer > Isilon Platforms Team > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 10:12:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9663CFB6; Wed, 1 Oct 2014 10:12:25 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5610DB74; Wed, 1 Oct 2014 10:12:25 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id EED891FE023; Wed, 1 Oct 2014 12:12:21 +0200 (CEST) Message-ID: <542BD381.4090808@selasky.org> Date: Wed, 01 Oct 2014 12:12:17 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Adrian Chadd , "O'Connor, Daniel" Subject: Re: What do you use for kernel debugging? References: <20140928071641.M7664@beckpeccoz.com> <20140929003358.M78145@aoek.com> <542AC1C8.9030101@freebsd.org> <90CE0701-F1CB-41DF-B3D2-87816DC03DF9@emc.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?Sm9zw6kgUMOpcmV6IEFyYXV6bw==?= , FreeBSD Current , Benjamin Kaduk , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 10:12:25 -0000 On 10/01/14 07:03, Adrian Chadd wrote: > There's also something for XHCI. > > Please please write it for freebsd. :) > > Hi, The FreeBSD bootloader can run a regular USB stack which connects to the XHCI/EHCI and any supported serial adapter for example. What is currently missing is some PCI pieces to attach the drivers. You don't need the USB debug port to get keyboard/console input. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 05:48:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8098E1F9B for ; Wed, 1 Oct 2014 05:48:16 +0000 (UTC) Received: from fmailer.gwdg.de (fmailer.gwdg.de [134.76.11.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F8E18E8 for ; Wed, 1 Oct 2014 05:48:15 +0000 (UTC) Received: from um-excht-a02.um.gwdg.de ([134.76.11.222] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (Exim 4.80) (envelope-from ) id 1XZClo-0002kz-SN; Wed, 01 Oct 2014 07:48:12 +0200 Received: from pc028.nfv (134.76.242.1) by email.gwdg.de (134.76.9.211) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Oct 2014 07:48:12 +0200 Message-ID: <542B9598.5030302@gwdg.de> Date: Wed, 1 Oct 2014 07:48:08 +0200 From: Rainer Hurling User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Chuck Burns , Subject: Re: pkg/ports system terribly messed up? References: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> <4180223.sAzr7DGzUz@blackbeast> In-Reply-To: <4180223.sAzr7DGzUz@blackbeast> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Level: - X-Virus-Scanned: (clean) by clamav X-Mailman-Approved-At: Wed, 01 Oct 2014 11:05:22 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 05:48:16 -0000 Am 01.10.2014 um 05:44 schrieb Chuck Burns: > On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote: >> Hello. >> >> I just made the last update of the ports yesterday (I use portmaster -da >> performing this task) and obviously or superficially everything went all >> right. >> > > > > It's portmaster actually. While it -usually- works great, I've noticed that > occassionally it loops like that. > > kill the script, upgrade the port that is looping. Because it seems that I have the same problem as Oliver: What script you are talking about? > > That usually fixes it. > From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 06:25:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 709B55D7; Wed, 1 Oct 2014 06:25:15 +0000 (UTC) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd51.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AB9DC75; Wed, 1 Oct 2014 06:25:14 +0000 (UTC) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s916P5pZ016077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 02:25:05 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s916P5pZ016077 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1412144706; bh=JES/pB8CdpAHwyy2QSnS6MnNbz4=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=lu0F/CmhVhL1yY/VC8q7x+D5lhTZZTX2xxjYpPimyL2LDzYf+NKfcJ8yhBgSFRcY7 q6iMRmEHPNHmQJZ5LyjZ1UBJolH3C+u7d4tghiUYKelu4ecmibDyNsF18PFqEHc2wQ 44SMEmFTgs+U0o46OVt/21L1ZbeZ8LcFThAFWyMI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com s916P5pZ016077 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 1 Oct 2014 02:24:44 -0400 Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s916Ot13017415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Oct 2014 02:24:55 -0400 Received: from mx34a.corp.emc.com ([169.254.1.46]) by mxhub36.corp.emc.com ([::1]) with mapi; Wed, 1 Oct 2014 02:24:54 -0400 From: "O'Connor, Daniel" To: Adrian Chadd Date: Wed, 1 Oct 2014 02:24:53 -0400 Subject: Re: What do you use for kernel debugging? Thread-Topic: What do you use for kernel debugging? Thread-Index: Ac/dQGnUMFw7GxaATdyBGcT7UFJmAg== Message-ID: <3718AED6-9514-49F9-AF11-B47CFAF01161@emc.com> References: <20140928071641.M7664@beckpeccoz.com> <20140929003358.M78145@aoek.com> <542AC1C8.9030101@freebsd.org> <90CE0701-F1CB-41DF-B3D2-87816DC03DF9@emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Wed, 01 Oct 2014 11:05:46 +0000 Cc: "O'Connor, Daniel" , =?Windows-1252?Q?Jos=E9_P=E9rez_Arauzo?= , FreeBSD Current , Benjamin Kaduk , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 06:25:15 -0000 On 1 Oct 2014, at 14:33, Adrian Chadd wrote: > There's also something for XHCI. So I see.. Section 7.6 in here has details.. http://www.intel.com.au/content/dam/www/public/us/en/documents/technical-sp= ecifications/extensible-host-controler-interface-usb-xhci.pdf Interestingly unlike the EHCI version it does not require hardware between = the debugger and debugee, only a special cable. (see http://msdn.microsoft.= com/en-us/library/windows/hardware/hh439372(v=3Dvs.85).aspx) A quick search shows the cable is pretty cheap ($15 for a short one) > Please please write it for freebsd. :) Not sure I have the cycles :( >=20 > -a >=20 >=20 > On 30 September 2014 21:45, O'Connor, Daniel wr= ote: >>=20 >> On 1 Oct 2014, at 0:14, Julian Elischer wrote: >>> Unfortunately you can't use a USB serial as it requires the USB stack >>> be working before it can be used.. >>> similar with ethernet connected debugging which requires that the >>> driver for the ethernet hardware support it. >>> (which why we don't have it in the tree though it has been done >>> several times in the past). >>=20 >> There IS a USB debug standard, Linux has some code to support it. >>=20 >> I am not sure what percentage of hardware has it hooked up though (the h= ost controller has a designated debug port but it could physically be anyth= ing). >>=20 >> http://www.coreboot.org/EHCI_Debug_Port >>=20 >> The hardware is bit more expensive than a null modem or firewire cable t= hough :( >>=20 >> Regards, >> Daniel O=92Connor >>=20 >> Senior Software Engineer >> Isilon Platforms Team >>=20 >>=20 >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" Regards, Daniel O=92Connor Senior Software Engineer Isilon Platforms Team From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 17:40:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0670F4BF for ; Wed, 1 Oct 2014 17:40:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5E13B09 for ; Wed, 1 Oct 2014 17:40:32 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C712AB949 for ; Wed, 1 Oct 2014 13:40:31 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: [PATCH] Fix OACTIVE for an(4) Date: Wed, 01 Oct 2014 10:14:54 -0400 Message-ID: <2113392.UOaBFTpimf@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 01 Oct 2014 13:40:31 -0400 (EDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 17:40:33 -0000 This small patch correctly sets OACTIVE when an(4) gets backed up. Right now I believe it will never set the flag. It is only an optimization, it should not affect correctness. Index: an/if_an.c =================================================================== --- an/if_an.c (revision 270968) +++ an/if_an.c (working copy) @@ -2906,11 +2906,11 @@ CSR_WRITE_2(sc, AN_INT_EN(sc->mpi350), AN_INTRS(sc->mpi350)); } - if (m0 != NULL) + if (sc->an_rdata.an_tx_prod != idx) { ifp->if_drv_flags |= IFF_DRV_OACTIVE; + sc->an_rdata.an_tx_prod = idx; + } - sc->an_rdata.an_tx_prod = idx; - return; } -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 18:09:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D50ECCA5; Wed, 1 Oct 2014 18:09:33 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 959C7EB9; Wed, 1 Oct 2014 18:09:33 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s91I9WKw062788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 11:09:32 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s91I9Wjt062787; Wed, 1 Oct 2014 11:09:32 -0700 (PDT) (envelope-from jmg) Date: Wed, 1 Oct 2014 11:09:32 -0700 From: John-Mark Gurney To: Allan Jude Subject: Re: zpool frag Message-ID: <20141001180932.GA43300@funkthat.com> Mail-Followup-To: Allan Jude , freebsd-current@freebsd.org References: <1411289830171-5950788.post@n5.nabble.com> <541EE962.2000801@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <541EE962.2000801@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 01 Oct 2014 11:09:32 -0700 (PDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:09:33 -0000 Allan Jude wrote this message on Sun, Sep 21, 2014 at 11:06 -0400: > On 2014-09-21 04:57, Beeblebrox wrote: > > FRAG means fragmentation, right? Zpool fragmentation? That's news to me. If > > this is real how do I fix it? > > > > NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HEALTH ALTROOT > > pool1 75.5G 53.7G 21.8G 60% - 71% 1.00x ONLINE - > > pool2 48.8G 26.2G 22.6G 68% - 53% 1.00x ONLINE - > > pool3 204G 177G 27.0G 53% - 86% 1.11x ONLINE - > > > > Regards. > > > > > > > > ----- > > FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS > > -- > > View this message in context: http://freebsd.1045724.n5.nabble.com/zpool-frag-tp5950788.html > > Sent from the freebsd-current mailing list archive at Nabble.com. > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > It is not something you 'fix', it is just a metric to help you > understand the performance of your pool. The higher the fragmentation, > the longer it might take to allocate new space, and obviously you will > have more random seek time while reading from the pool. > > As Steven mentions, there is no defragmentation tool for ZFS. You can > zfs send/recv or backup/restore the pool if you have a strong enough > reason to want to get the fragmentation number down. > > It is a fairly natural side effect of a copy-on-write file system. > > Note: the % is not the % fragmented, IIRC, it is the percentage of the > free blocks that are less that a specific size. I forget what that size is. Can we get this documented in the zpool man page? I assume that the FRAG is the same as: fragmentation The amount of fragmentation in the pool. and that description is woefully lacking.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 18:12:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C435CE96 for ; Wed, 1 Oct 2014 18:12:33 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 968BEF93 for ; Wed, 1 Oct 2014 18:12:33 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s91ICWFK062846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 11:12:32 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s91ICW6B062845; Wed, 1 Oct 2014 11:12:32 -0700 (PDT) (envelope-from jmg) Date: Wed, 1 Oct 2014 11:12:32 -0700 From: John-Mark Gurney To: Larry Rosenman Subject: Re: Intel SoC's Message-ID: <20141001181232.GB43300@funkthat.com> Mail-Followup-To: Larry Rosenman , Freebsd current References: <04c8c6dd4961e5097cb7e9f21e6c3ae1@thebighonker.lerctr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04c8c6dd4961e5097cb7e9f21e6c3ae1@thebighonker.lerctr.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 01 Oct 2014 11:12:32 -0700 (PDT) Cc: Freebsd current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:12:33 -0000 Larry Rosenman wrote this message on Sun, Sep 21, 2014 at 21:13 -0500: > I got 2 Intel SoC's at the Intel IOT Hackathon here in Austin this > weekend. > > They are both I586/Pentium processors, with some other stuff hanging > out. They currently run Yactoh Linux. > > I'm wondering how hard it would be to get FreeBSD up on them.... > > They are the Galileo Gen 2, and Edison boards. > > Any ideas on how/where to start? Just install FreeBSD on them? If you can't boot from USB, it isn't hard to build and install a new dist on an SD card or other media to boot from.. I recently ran up FreeBSD on an old K6/200, so close to same era, and it just worked... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 18:14:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44522177 for ; Wed, 1 Oct 2014 18:14:53 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15A76FC5 for ; Wed, 1 Oct 2014 18:14:53 +0000 (UTC) Received: by mail-ig0-f178.google.com with SMTP id l13so892706iga.5 for ; Wed, 01 Oct 2014 11:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=aZhGsYKzwxctMuPgDBxB+Qhzc9k/JkbxWkugYgKXykA=; b=YB/Xng0GJyua3ARJbfoXnIze8ZBB40TPiPCgL1Q9onMV66E5E5yo2uWW01t3UBU+yP 0v+ekeZbgJIpUZz4Ed+7nKsCulntENKxeRaex+mhX8BznyVs91WEBraw27IKt4PLVgPu 9z/Qp0pdV5uxpEakCNnwIk6s6kiTAUM5lJHDy9eGf9V4gr/SwOzH/tI1GaibAQ4SlDKq LDbZD81uacVO9LhDwTNH6V14PsZNPLLKsg0kReZ5sRqGpEf5aU+ut8Qek6CRfyGQdAo6 7Zu+MGJpy6v6wafWc9ms4a6p27V1KobgvYHA8ixtEjsest6P3uyKhX2AB87rWpcD1xZv 0HGg== X-Received: by 10.50.43.136 with SMTP id w8mr45100igl.33.1412187292614; Wed, 01 Oct 2014 11:14:52 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.44.196 with HTTP; Wed, 1 Oct 2014 11:14:32 -0700 (PDT) In-Reply-To: <20141001181232.GB43300@funkthat.com> References: <04c8c6dd4961e5097cb7e9f21e6c3ae1@thebighonker.lerctr.org> <20141001181232.GB43300@funkthat.com> From: Ed Maste Date: Wed, 1 Oct 2014 14:14:32 -0400 X-Google-Sender-Auth: 7gecv76gJp-UMJszUy8jtB_r0d4 Message-ID: Subject: Re: Intel SoC's To: Larry Rosenman , Freebsd current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:14:53 -0000 On 1 October 2014 14:12, John-Mark Gurney wrote: > > Just install FreeBSD on them? If you can't boot from USB, it isn't > hard to build and install a new dist on an SD card or other > media to boot from.. As far as I know Galileo only boots from UEFI and we don't yet have i386 UEFI boot bits. From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 18:58:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B60EC95; Wed, 1 Oct 2014 18:58:41 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 789AC759; Wed, 1 Oct 2014 18:58:40 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id z12so1322867wgg.1 for ; Wed, 01 Oct 2014 11:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/U62aYkrTqk60tqG6E04yDWbHSACN/l5NCZRVISflhU=; b=yH6hrcDMSxhzI8gbWUWBhBDY7S+Nm5HBvlq2mn3AuEi/vt/w7t0tVu9E6cr91mK7o5 Gt8r3A4qnnZeFMgLksiDm7llzuHQbN1OqIwO92KJVA4IqF4whijEdbW0l/pgrVQPtrfA Ikf+B2IBygsfgWZRY6xk/8K6/ZX8kDTXjVV9fiAAOxGQe9VNAaRxfdxOirnh6+/kr/gz 0Svh2F7Xyizqu4VHxp8qIlno/gFWX3PDNhvNPvIQolN2mgTmN7DPMeVDJsj7cOCcvYtq WQ4A4mwID9ZTWDQ2ns0Me8QAYVonpo+Pz4xEVk46QH4tNgGy5Namcf4joKEGSzosCDKs BEWg== MIME-Version: 1.0 X-Received: by 10.194.202.138 with SMTP id ki10mr40773096wjc.68.1412189918636; Wed, 01 Oct 2014 11:58:38 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 1 Oct 2014 11:58:38 -0700 (PDT) In-Reply-To: <2113392.UOaBFTpimf@ralph.baldwin.cx> References: <2113392.UOaBFTpimf@ralph.baldwin.cx> Date: Wed, 1 Oct 2014 11:58:38 -0700 X-Google-Sender-Auth: dt0eFRxLUoxzQQ5vl7kEKff9-1E Message-ID: Subject: Re: [PATCH] Fix OACTIVE for an(4) From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 18:58:41 -0000 Hi, On 1 October 2014 07:14, John Baldwin wrote: > This small patch correctly sets OACTIVE when an(4) gets backed up. Right now > I believe it will never set the flag. It is only an optimization, it should > not affect correctness. > > Index: an/if_an.c > =================================================================== > --- an/if_an.c (revision 270968) > +++ an/if_an.c (working copy) > @@ -2906,11 +2906,11 @@ > CSR_WRITE_2(sc, AN_INT_EN(sc->mpi350), AN_INTRS(sc->mpi350)); > } > > - if (m0 != NULL) > + if (sc->an_rdata.an_tx_prod != idx) { > ifp->if_drv_flags |= IFF_DRV_OACTIVE; > + sc->an_rdata.an_tx_prod = idx; > + } > > - sc->an_rdata.an_tx_prod = idx; > - > return; > } I haven't looked at the rest of the driver; is everything else around OACTIVE locked correctly and consistently? There's no single-entry into if_start(). It can be called from multiple paths at the same time. -a From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 19:12:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 209BD256 for ; Wed, 1 Oct 2014 19:12:25 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AAB7392F for ; Wed, 1 Oct 2014 19:12:24 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id a1so1308910wgh.33 for ; Wed, 01 Oct 2014 12:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=CSIDatsNu/jtsKqCagwXKJ0RVnbw7yUXnfRYPK+MzE8=; b=VMa/3bT9S6lw8fd4NcjMIKMSUv/lqA5JgRoWLq3f37bV/C73RFOiShFKzvevkgKiGd MZ3QK3eWbRL8FiWYnroD2Jk8k3YRklCL96DregNbK7d1j9bJvoIwvnfJnm3yaeKcMH6o aAf32RDhRZTrUiWDrG0XyCGVDQwaOf0TADIX2HwmyorMwk0xFUq/zi9L+hAj9aU0jFrk BZOl3EdmHvG3+HPgalqW5srkCHy7y4ZsBhsTKkvSenUmLixjYATjHmZZiXPqfncfsqEz KCFHZ505JX11AX7xoaUcQmODxftvdHPfDvBmednUTZUOX2s518vmUrvCzGiLIR5yx0Ob NF5w== MIME-Version: 1.0 X-Received: by 10.180.101.129 with SMTP id fg1mr16885338wib.20.1412190742918; Wed, 01 Oct 2014 12:12:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 1 Oct 2014 12:12:22 -0700 (PDT) In-Reply-To: <542BD381.4090808@selasky.org> References: <20140928071641.M7664@beckpeccoz.com> <20140929003358.M78145@aoek.com> <542AC1C8.9030101@freebsd.org> <90CE0701-F1CB-41DF-B3D2-87816DC03DF9@emc.com> <542BD381.4090808@selasky.org> Date: Wed, 1 Oct 2014 12:12:22 -0700 X-Google-Sender-Auth: ZkkOajCAK0C7OOcdW5IQnZkZ0g4 Message-ID: Subject: Re: What do you use for kernel debugging? From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: "O'Connor, Daniel" , FreeBSD Current , Benjamin Kaduk , Garrett Cooper , =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez_Arauzo?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 19:12:25 -0000 On 1 October 2014 03:12, Hans Petter Selasky wrote: > On 10/01/14 07:03, Adrian Chadd wrote: >> >> There's also something for XHCI. >> >> Please please write it for freebsd. :) >> >> > > Hi, > > The FreeBSD bootloader can run a regular USB stack which connects to the > XHCI/EHCI and any supported serial adapter for example. What is currently > missing is some PCI pieces to attach the drivers. You don't need the USB > debug port to get keyboard/console input. We actually _want_ the debug port support. The EHCI/XHCI debugging stuff is separate from the whole normal USB stack and is really designed for lower level debugging - ie, when everything is actually busted. Think of it as being the polled conduit for doing remote kgdb and (hopefully, with the XHCI stuff) remote memory inspection when things go off the deep end. -a From owner-freebsd-current@FreeBSD.ORG Wed Oct 1 20:17:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5C23C3B; Wed, 1 Oct 2014 20:17:58 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6DEFBFD4; Wed, 1 Oct 2014 20:17:58 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id uq10so1114638igb.13 for ; Wed, 01 Oct 2014 13:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DLXcQXtJ0/dDQWHY7DOTeVrvti3bNAHZm9C4ptgXYD0=; b=W9cy/1idD21TMfjKpuC0Nj5+T8gqBp9NdKEMVYnB/qg161LbYMv6EeR5ytbZOJVYoQ i7HK+QSA6K4HWfzeIMSFc0k/esGAgjnewWR10c04jMWDzp37EvtQZYfSWcyfgRHNrRw+ 0zfDq/rLgEL9z4H0Mwkx6/xDTy6YXpN155Y/WnQV8JSRRGm9IxflQiwagfrktYPGtmth oXx8YP0f0DbmOr/n04/xbf8tkUluyVaAxxx9rLQwTmMQi+IVIZuZVr30GHX4txFRh2PB LqEvjNSuda+dwZ3h8rMFU7GvgJjg7FcSnS6XttjXO2jV4je38acNJ8gi7ugXz4jjcGgw 0AFA== MIME-Version: 1.0 X-Received: by 10.50.114.38 with SMTP id jd6mr23317212igb.26.1412194677914; Wed, 01 Oct 2014 13:17:57 -0700 (PDT) Received: by 10.50.227.42 with HTTP; Wed, 1 Oct 2014 13:17:57 -0700 (PDT) In-Reply-To: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> References: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> Date: Wed, 1 Oct 2014 13:17:57 -0700 Message-ID: Subject: Re: pkg/ports system terribly messed up? From: NGie Cooper To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD CURRENT , FreeBSD Ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 20:17:58 -0000 On Mon, Sep 29, 2014 at 11:13 PM, O. Hartmann wrote: > > Hello. > > I just made the last update of the ports yesterday (I use portmaster -da performing this > task) and obviously or superficially everything went all right. > > I'm running on the boxes in question most recent CURRENT. > > On one system, a subsequent start of updating ports starts to freak out when updateing > lang/gcc: it loops over and over on some ports already updated, especially > devel/binutils, but the port looping on isn't specific and varies. > > On every CURRENT box I tried this morning to update the ports again, I find this > frsutrating message (depends on installation, but it seems in principal the same, only > the affected ports in dependency chain varies): Are you using portmaster? If so, it might be fallout from r272282. Cheers, From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 02:40:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E988B7C2 for ; Thu, 2 Oct 2014 02:40:09 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5DF3242 for ; Thu, 2 Oct 2014 02:40:09 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id r5so1529273qcx.21 for ; Wed, 01 Oct 2014 19:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:content-type; bh=ljXbklJPLhndeimpcFcDx8oXUdfDLLDR5DTC/reFcts=; b=HD1GvlySnRFSSDIIDem4hsG7U+P+OcZ0IMqRif0dDDSs28usuQ4cKIDBI1M2kIvCB2 nzqDluIbvgkR4Mu8cpTFzYAM1YNzf0YYqzqRRYGk7kpGD/CzytK9A1lrcrusuU+qQVd2 XrSAmUcvckmY41LDefTshgYJJCwZ6VTRlOHkMY/lGL0DZ97UmjFIy3DW184RYp8NAmIn 7cjE+zh6aIld2R/E96jw1X8JJqB1+Q/+28YDvmzebJ/gWlCvoAAAYKtyHNc8Cw1Qq+B2 Hy0chJZwlmDNW2TdhU/+oy3hODRzLCmPgrZyQFOLyQmR7g5KpYumd4virrZPBezLoKpc U8VQ== X-Received: by 10.224.115.14 with SMTP id g14mr44863759qaq.23.1412217608765; Wed, 01 Oct 2014 19:40:08 -0700 (PDT) Received: from blackbeast.localnet (173-26-254-198.client.mchsi.com. [173.26.254.198]) by mx.google.com with ESMTPSA id s4sm2238693qay.36.2014.10.01.19.40.08 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Oct 2014 19:40:08 -0700 (PDT) From: Chuck Burns To: freebsd-current@freebsd.org Subject: Re: pkg/ports system terribly messed up? Date: Wed, 01 Oct 2014 21:40:35 -0500 Message-ID: <3029778.sRTk01SrzP@blackbeast> User-Agent: KMail/4.13.3 (Linux/3.10.17; KDE/4.13.3; x86_64; ; ) In-Reply-To: <542B9598.5030302@gwdg.de> References: <20140930081301.55bc5629.ohartman@zedat.fu-berlin.de> <4180223.sAzr7DGzUz@blackbeast> <542B9598.5030302@gwdg.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 02:40:10 -0000 On Wednesday, October 01, 2014 7:48:08 AM Rainer Hurling wrote: > Am 01.10.2014 um 05:44 schrieb Chuck Burns: > > On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote: > >> Hello. > >> > >> I just made the last update of the ports yesterday (I use portmaster -da > >> performing this task) and obviously or superficially everything went all > >> right. > > > > > > > > It's portmaster actually. While it -usually- works great, I've noticed > > that occassionally it loops like that. > > > > kill the script, upgrade the port that is looping. > > Because it seems that I have the same problem as Oliver: What script you > are talking about? > > > That usually fixes it. portmaster is just a (not-so-)simple shell script. Kill portmaster (CTRL-C a few times) then build the offending port with "make && make deinstall reinstall clean" -- Chuck From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 05:07:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E874CB7 for ; Thu, 2 Oct 2014 05:07:42 +0000 (UTC) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E5C522B1 for ; Thu, 2 Oct 2014 05:07:41 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id fb1so1591388pad.25 for ; Wed, 01 Oct 2014 22:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=3OnPcI4nwjTTNOTtnFuVrngOcdnCs5wDE9/o0SOleYQ=; b=zP/8jwCXUS073jYEry7FQGZh+XIQHAaEUt/kIhvV4xa2rSD0+Wucm2IvF6qLSdpU4g XPkvkWffFI11hxllsj9j9JyAPizcBlbUyP3mv8SILqDKE3k2F/d2UaLTv/62OELBujWt SqdFa358WRNiXqeYQM3WskCMGAA1ytmKm6Vxvm8Jnt7gJi87S6j9ReO4AcvjyLDqowvo eVfeTnmNrBsq2iyai+BJIdwMvB0INsInnHKb2+dcQsOxVDhp0BQlJH/Cwkua3gTr6s2K owsiEnO9c7JerBtNncos50stF90+DQgFvMaeF/VCe1ebkFs9o+glsVCNo2Kj4gIVsXFr S7pQ== X-Received: by 10.68.136.2 with SMTP id pw2mr85383529pbb.39.1412226461255; Wed, 01 Oct 2014 22:07:41 -0700 (PDT) Received: from pyunyh@gmail.com ([106.247.248.2]) by mx.google.com with ESMTPSA id zn2sm2391316pbb.41.2014.10.01.22.07.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Oct 2014 22:07:39 -0700 (PDT) From: Yonghyeon PYUN X-Google-Original-From: "Yonghyeon PYUN" Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 02 Oct 2014 14:07:30 +0900 Date: Thu, 2 Oct 2014 14:07:30 +0900 To: freebsd-current@freebsd.org Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support Message-ID: <20141002050730.GA964@michelle.fasterthan.com> Reply-To: pyunyh@gmail.com References: <20140930015741.GA2451@michelle.fasterthan.com> <20141001013637.GD2632@michelle.fasterthan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141001013637.GD2632@michelle.fasterthan.com> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 05:07:42 -0000 On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote: > On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote: > > Hi, > > I've added support for QAC AR816x/AR817x ethernet controllers. It > > passed my limited testing and I need more testers. You can find > > patches from the following URLs. > > > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff > > and > > http://people.freebsd.org/~yongari/alc/alc.diff.20140930 > > > > pci.qurik.diff is to workaround silicon bug of AR816x. Without it > > MSI/MSIX interrupt wouldn't work. If you just want to use > > legacy INTx interrupt you don't have to apply it but you have to > > tell alc(4) not to use MSI/MSIX interrupt with tunables( > > hw.alc.msi.disable and hw.alc.msix_disable). > > > > alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172 > > and E2200 controllers. It supports all hardware features except > > RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x > > controllers please test and report how the diff works for you. > > Thanks. > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff > http://people.freebsd.org/~yongari/alc/alc.diff.20141001 > > Patch updated to address link establishment issue. http://people.freebsd.org/~yongari/alc/alc.diff.20141002 Patch updated again to correct wrong lock assertion. From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 08:48:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59B45985 for ; Thu, 2 Oct 2014 08:48:42 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D689FE15 for ; Thu, 2 Oct 2014 08:48:41 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id w7so1761259lbi.8 for ; Thu, 02 Oct 2014 01:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=xf1mlT83qLNAilSaag5equ/uRiMViQFuuC+8FJshpmg=; b=r4mY1CfUcQ3aSDKF7568Lb3EwYDzbiKJ4Mi4QBli/pfcm+zUig0gv6CtHyY2DDnSTO 5YHSZ5LkXNGgir0kyzagxAaNqmRdkI7IwxOl7YhDuU74JjOu9mSZQ1hIlPwMljph/yue CReB283Qzd7GxpY8G1uR74Ae8EBjL71SmRR1BgMEEJjgY0U7LTDY9eAgJ+12hUG8ZJpH axEwbwcp8O+Ro4MZc1L2h+e2xpV4rKukVyIBxLkE9dLMGtFTMa1e3APRS2GLnqm1yi2F Tp3wuMQZVENg/nD79rJ6iU/VH3rnpkMx+lseZOgne1k+h5GXbz4ZvO0BCbl1FoZrPcQU CB3A== MIME-Version: 1.0 X-Received: by 10.152.36.4 with SMTP id m4mr61688448laj.17.1412239719692; Thu, 02 Oct 2014 01:48:39 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Thu, 2 Oct 2014 01:48:39 -0700 (PDT) Date: Thu, 2 Oct 2014 01:48:39 -0700 X-Google-Sender-Auth: vQz8rinsp56Tp_7zGpq_a95iqRQ Message-ID: Subject: FreeBSD laptop compatibility list web page? From: Craig Rodrigues To: freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 08:48:42 -0000 Hi, I e-mailed Lukas Ertl about the FreeBSD Laptop compatibility list web page which used to be at: http://laptop.bsdgroup.de/freebsd/ but got no response. That was a really nice web page, and it is a shame it is no longer accessible. Does anyone know if the content has been moved elsewhere? There are some archives of it here: http://archive.today/laptop.bsdgroup.de It would be nice to get the content of that page and move it somewhere more permanent, maybe to the PC-BSD or FreeBSD wiki pages. -- Craig From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 09:23:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 912A83B5; Thu, 2 Oct 2014 09:23:04 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6BE825D; Thu, 2 Oct 2014 09:23:03 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id pv20so2013336lab.34 for ; Thu, 02 Oct 2014 02:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=XSwE0OMPOqKU7ToKve5yQazyw7WQj+C5H0q6kF8UH0E=; b=PdAJDfxdxohjpTYODBNggrwlCzQ3oewICfybIGFewkJ2YRSUyKU+LdYldTcdtUqh9w gWAk1kdev89hTQD5OtF3uzSnDx/hG5/IUXyzZ/ePQV3O8LYpqY6ZSqagc0plnUqJaY97 lTnrox+N5EYFB0sd5VqLos+KoQuGDn30lxxaYafkxh90rjhH1sPL3prsEMzrGxFrjSU3 Fd6k6YxTBAQZmmRJ8mZ2Fto4JcTMeSZnYj+iJp7XtOy7prKYKTYdlKYWDURc08gMaY13 fW7XP8j46wwn58+VQWYDLe7xn08KD1rhpUGDF7oJtm/cOOKT6DLEI9bFQ22/aXVcvs2W 7Qhg== MIME-Version: 1.0 X-Received: by 10.112.54.130 with SMTP id j2mr28041612lbp.41.1412241781787; Thu, 02 Oct 2014 02:23:01 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.131.66 with HTTP; Thu, 2 Oct 2014 02:23:01 -0700 (PDT) Date: Thu, 2 Oct 2014 02:23:01 -0700 X-Google-Sender-Auth: B8gCUADVG-8vKYfNMq8K_SGUQic Message-ID: Subject: Need help debugging yacc test failure in CURRENT From: Craig Rodrigues To: freebsd-current Current , "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 09:23:04 -0000 Hi, I have managed to eliminate all the test failures from /usr/tests in CURRENT except for one failure. See: https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/8/testReport/ I can reproduce the failure by doing the following: mkdir /tmp/x cd /tmp/x /usr/tests/usr.bin/yacc/yacc_tests usr.bin.yacc.yacc_tests.main I then get a core file: /tmp/x/test/yacc.core Can someone help debug and fix this? Thanks. -- Craig From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 09:26:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF34B51B; Thu, 2 Oct 2014 09:26:17 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88338288; Thu, 2 Oct 2014 09:26:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=rfVVX9EpjJ99beVOwtrmUcvpTFSleo3pLCHh006LSCU=; b=f8lLAApGYdjFsbGiQ20m+AXAUoC3ofvhMbnXabL+3pj7zjrQzjWKOBUwDROuwFDNosbst6yOc60oGUOkLqKG4vwhnp8y6b3y5yWgEsFUjUkQgTuUHGIdKk5ts9hiA6ms+HXNwZgti+EjqsVBjX5C3xRsFNNfrMXeM5OalW+Aoig=; Received: from [182.4.74.116] (port=34522 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZceI-000twq-0M; Thu, 02 Oct 2014 03:26:10 -0600 Date: Thu, 2 Oct 2014 17:26:06 +0800 From: Erich Dollansky To: Craig Rodrigues Subject: Re: FreeBSD laptop compatibility list web page? Message-ID: <20141002172606.7645e26b@X220.alogt.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 09:26:17 -0000 Hi, On Thu, 2 Oct 2014 01:48:39 -0700 Craig Rodrigues wrote: > Hi, > > I e-mailed Lukas Ertl about I think that you to the wrong URL. The university of vienna is here: http://www.univie.ac.at Erich From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 10:41:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9C96F01; Thu, 2 Oct 2014 10:41:21 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 914CDC28; Thu, 2 Oct 2014 10:41:20 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id C09E86A6003; Thu, 2 Oct 2014 12:41:17 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id s92AfHVv017746; Thu, 2 Oct 2014 12:41:17 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id s92AfGgg016978; Thu, 2 Oct 2014 12:41:16 +0200 (CEST) (envelope-from lars) Date: Thu, 2 Oct 2014 12:41:16 +0200 From: Lars Engels To: Erich Dollansky Subject: Re: FreeBSD laptop compatibility list web page? Message-ID: <20141002104116.GU20243@e-new.0x20.net> Mail-Followup-To: Lars Engels , Erich Dollansky , Craig Rodrigues , freebsd-current Current References: <20141002172606.7645e26b@X220.alogt.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SqO8Hf1xXlNBrDgg" Content-Disposition: inline In-Reply-To: <20141002172606.7645e26b@X220.alogt.com> X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p16 User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Craig Rodrigues , freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 10:41:21 -0000 --SqO8Hf1xXlNBrDgg Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 02, 2014 at 05:26:06PM +0800, Erich Dollansky wrote: > Hi, >=20 > On Thu, 2 Oct 2014 01:48:39 -0700 > Craig Rodrigues wrote: >=20 > > Hi, > >=20 > > I e-mailed Lukas Ertl about >=20 > I think that you to the wrong URL. The university of vienna is here: >=20 > http://www.univie.ac.at >=20 The Laptop Compability list was first created by Lukas and hosts at the University of Vienna. When it wasn't maintained any longer some people of bsdgroup.de were allowed to host and maintain the page on their domain. Unfortunately, bsdgroup.de isn't active for years, so eventually the Laptop Compability List disappeared. Given that it is outdated for a long time, we should probably let it rest in peace and use https://wiki.freebsd.org/Laptops as a new reference. IIRC the old list was flooded by spammers, so at least that problem is solved as the FreeBSD Wiki is only for registered people who have been nodded through by FreeBSD developers. --SqO8Hf1xXlNBrDgg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJULSvMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1tz6cH/jP+VOuM8UkJbglQDgV/ChES i7hQCcE2r6MA8isdA/SjY1eCFokKI858vucJpMDjqnCxNcdK/kQ0Stj7kGklttBj 9UVd2wRYkCklfWsncHOxkxqAzp2NwIRCy0HTKtIradzbJED/0Rqf/lWq4HGdn0xj 3dveP2kv7mQGVckecpmzatmm5eUO22+sHMv5OVeZIle/ajUM71hNJ1NHmbLIxVXb tS+HOBO0vqWFJxujSVl9WDA+0Qz3jc0hTbkiJKVLpm7c4wDW2vmuzVqh2o4oY9I0 2CWa8d2IDPIJO6ICH58lSKLBIwK2ibiPhPcVzCMBZoHE1pxO7jK/zti5TUwGRe4= =bESo -----END PGP SIGNATURE----- --SqO8Hf1xXlNBrDgg-- From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 15:59:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7BB29CD; Thu, 2 Oct 2014 15:59:51 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B09AC817; Thu, 2 Oct 2014 15:59:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 52471B989; Thu, 2 Oct 2014 11:59:50 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: [PATCH] Fix OACTIVE for an(4) Date: Thu, 2 Oct 2014 11:16:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <2113392.UOaBFTpimf@ralph.baldwin.cx> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201410021116.27583.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 02 Oct 2014 11:59:50 -0400 (EDT) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 15:59:51 -0000 On Wednesday, October 01, 2014 2:58:38 pm Adrian Chadd wrote: > Hi, > > On 1 October 2014 07:14, John Baldwin wrote: > > This small patch correctly sets OACTIVE when an(4) gets backed up. Right now > > I believe it will never set the flag. It is only an optimization, it should > > not affect correctness. > > > > Index: an/if_an.c > > =================================================================== > > --- an/if_an.c (revision 270968) > > +++ an/if_an.c (working copy) > > @@ -2906,11 +2906,11 @@ > > CSR_WRITE_2(sc, AN_INT_EN(sc->mpi350), AN_INTRS(sc- >mpi350)); > > } > > > > - if (m0 != NULL) > > + if (sc->an_rdata.an_tx_prod != idx) { > > ifp->if_drv_flags |= IFF_DRV_OACTIVE; > > + sc->an_rdata.an_tx_prod = idx; > > + } > > > > - sc->an_rdata.an_tx_prod = idx; > > - > > return; > > } > > I haven't looked at the rest of the driver; is everything else around > OACTIVE locked correctly and consistently? As well as OACTIVE is for any other driver. > There's no single-entry into if_start(). It can be called from > multiple paths at the same time. Yes, I know. However, this bug is more that it will never set OACTIVE currently (m0 is always set to NULL before it gets to this point). This code in its stats timer is also dubious: /* Don't do this while we're transmitting */ if (ifp->if_drv_flags & IFF_DRV_OACTIVE) { callout_reset(&sc->an_stat_ch, hz, an_stats_update, sc); return; } sc->an_stats.an_len = sizeof(struct an_ltv_stats); sc->an_stats.an_type = AN_RID_32BITS_CUM; if (an_read_record(sc, (struct an_ltv_gen *)&sc->an_stats.an_len)) return; callout_reset(&sc->an_stat_ch, hz, an_stats_update, sc); First, the callout_reset() can just be moved earlier. Second, OACTIVE doesn't mean that anything is transmitting, it means the ring is full (at least in terms of how all other drivers use it). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 17:24:25 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9D1E7A0; Thu, 2 Oct 2014 17:24:24 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6109D351; Thu, 2 Oct 2014 17:24:24 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id d1so4685336wiv.8 for ; Thu, 02 Oct 2014 10:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6+EKjKUcCYhm6qGEVAHJft0U1U3Ed7hiyjC85K1qPfA=; b=ECy9Ayo4nmwr4rd4wwoGNQ4uz+qKyCJzIoKBiGLGeiJgmlk3r9n1XQlbJtc2CrNr/I 2PrIoCW8J5HbyME/pRT7xuwc7BzD8to1uMxkb44d9Ebike+RyShG1cnhmTe1+myWxxsB LoVOn6EU5i5DEjPwkTahvn70cZImvpoWrKKTtm3Sbgt1QvyUyVkgKTagvuMahYB2sRmg 3Z8N5EWGe5dzPVHrI1gwaktaK6FDNRXg+RFZ4a0chaHmmXQEvhG4S1RaR49dKc1gN15M qVEfM+pSrx894zhPLjvL6Eq/yqCFOusxo7xxAC560bbWwqt5kRdT1fCTODshRqHUfRjc 2i4g== MIME-Version: 1.0 X-Received: by 10.180.9.73 with SMTP id x9mr5939534wia.20.1412270662529; Thu, 02 Oct 2014 10:24:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Thu, 2 Oct 2014 10:24:22 -0700 (PDT) In-Reply-To: <201410021116.27583.jhb@freebsd.org> References: <2113392.UOaBFTpimf@ralph.baldwin.cx> <201410021116.27583.jhb@freebsd.org> Date: Thu, 2 Oct 2014 10:24:22 -0700 X-Google-Sender-Auth: UWrRQfSSSTFfeS9iL5ZOYdEv3c4 Message-ID: Subject: Re: [PATCH] Fix OACTIVE for an(4) From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:24:25 -0000 On 2 October 2014 08:16, John Baldwin wrote: > On Wednesday, October 01, 2014 2:58:38 pm Adrian Chadd wrote: >> Hi, >> >> On 1 October 2014 07:14, John Baldwin wrote: >> > This small patch correctly sets OACTIVE when an(4) gets backed up. Right > now >> > I believe it will never set the flag. It is only an optimization, it > should >> > not affect correctness. >> > >> > Index: an/if_an.c >> > =================================================================== >> > --- an/if_an.c (revision 270968) >> > +++ an/if_an.c (working copy) >> > @@ -2906,11 +2906,11 @@ >> > CSR_WRITE_2(sc, AN_INT_EN(sc->mpi350), AN_INTRS(sc- >>mpi350)); >> > } >> > >> > - if (m0 != NULL) >> > + if (sc->an_rdata.an_tx_prod != idx) { >> > ifp->if_drv_flags |= IFF_DRV_OACTIVE; >> > + sc->an_rdata.an_tx_prod = idx; >> > + } >> > >> > - sc->an_rdata.an_tx_prod = idx; >> > - >> > return; >> > } >> >> I haven't looked at the rest of the driver; is everything else around >> OACTIVE locked correctly and consistently? > > As well as OACTIVE is for any other driver. > >> There's no single-entry into if_start(). It can be called from >> multiple paths at the same time. > > Yes, I know. However, this bug is more that it will never set OACTIVE > currently (m0 is always set to NULL before it gets to this point). > > This code in its stats timer is also dubious: > > /* Don't do this while we're transmitting */ > if (ifp->if_drv_flags & IFF_DRV_OACTIVE) { > callout_reset(&sc->an_stat_ch, hz, an_stats_update, sc); > return; > } > > sc->an_stats.an_len = sizeof(struct an_ltv_stats); > sc->an_stats.an_type = AN_RID_32BITS_CUM; > if (an_read_record(sc, (struct an_ltv_gen *)&sc->an_stats.an_len)) > return; > > callout_reset(&sc->an_stat_ch, hz, an_stats_update, sc); > > First, the callout_reset() can just be moved earlier. > > Second, OACTIVE doesn't mean that anything is transmitting, it means the ring > is full (at least in terms of how all other drivers use it). yes, but if you don't absolutely handle it in a race-free situation, you end up never having if_start() called. IFQ_HANDOFF() -> IFQ_HANDOFF_ADJ() -> enqueue, then if it worked AND OACTIVE==0, call if_start() Then you hit the stupid situation where OACTIVE was set just long enough for the queue to fill up without calling if_start(), then once it's filled if_start() won't ever be called from the transmitter context. It has to be called from the completion context or the receive context. Or, well, anywhere. All of that stuff needs to die. -a From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 17:57:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ECA75699 for ; Thu, 2 Oct 2014 17:57:10 +0000 (UTC) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC16D932 for ; Thu, 2 Oct 2014 17:57:10 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id j5so2292367qga.31 for ; Thu, 02 Oct 2014 10:57:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=Stce99MZurYjhmAtIGBjT2nZ9de9LkobVz3TyM4/KXE=; b=hCAx6mnQFEFjXRfUAdNew1GIItoI0zLv9kM5KgBZN8NI4hl728hDGroW91BRol2+TC vnaCpKxpLa6vXfrxwOskB4mbpIIOdMOVGci9kPtDKqNBklSbPLBFZfd6bmVEtQAqlyRh Ui7T81o2hQPgo6AdRcllZUepG6U3psc/lf6RpIlWaBujt9curhl8+SBjbDisl7WHFevi miQNtJozOPocQ508yCIM/JqzDKqO2dFf26UJsVlaV/DXDEzN5H+RxESRQx+IIveXLpYU CCtjxlLU9hl7aqYet9eiSqE9p09JTM7FmQlMxkfz0lrtl3H5ov5ag3Zt5RbY/n817eal 7ldg== X-Gm-Message-State: ALoCoQk01PfpxRi3sy+pRkTJtcj7lmesTfHTHbxp0muz0O+PEbgB7NfNYDnOi+7dy8orCJrrvmiY X-Received: by 10.140.92.199 with SMTP id b65mr667160qge.86.1412272622640; Thu, 02 Oct 2014 10:57:02 -0700 (PDT) MIME-Version: 1.0 Sender: jmmv@meroh.net Received: by 10.96.75.134 with HTTP; Thu, 2 Oct 2014 10:56:42 -0700 (PDT) X-Originating-IP: [2620:0:1003:1007:f94e:df22:a7b5:d386] In-Reply-To: References: From: Julio Merino Date: Thu, 2 Oct 2014 13:56:42 -0400 X-Google-Sender-Auth: lO0e1XfCzo1Y0LXfhgExJlghWY0 Message-ID: Subject: Re: Need help debugging yacc test failure in CURRENT To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current Current , "freebsd-testing@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 17:57:11 -0000 On Thu, Oct 2, 2014 at 5:23 AM, Craig Rodrigues wrote: > Hi, > > I have managed to eliminate all the test failures from /usr/tests in CURRENT > except for one failure. See: > > https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/8/testReport/ > > I can reproduce the failure by doing the following: > > mkdir /tmp/x > cd /tmp/x > /usr/tests/usr.bin/yacc/yacc_tests usr.bin.yacc.yacc_tests.main > > I then get a core file: /tmp/x/test/yacc.core > > Can someone help debug and fix this? What you'd do until someone fixes the yacc bug is file a PR for this crash and then mark the test as "expected failure" (or TODO in TAP terms). From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 18:10:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17CBDBC; Thu, 2 Oct 2014 18:10:21 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C369AA9B; Thu, 2 Oct 2014 18:10:20 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id lf10so3054060pab.16 for ; Thu, 02 Oct 2014 11:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=soDkSsiG5V1BUk0l9OZmhoztRQNYizQLdnL33x78Lr8=; b=K9tQ8oEsAZk6Q+XXUE7MmuxsKTM52BO2cy+xS2od/T0BcXk/OxGWTMBH3dUUQf6fcy OOZ0mRsru8LevXkUUhG9+sst9mf9Ejhb6y1n9wcbNMC//chdaQf5V8cvu9Wn+7hFba7R J0yQ0SmzF5nKGX6b2iqtZFQOOI/4IyxoWZvGd1b5PwI4+xJlc+4qCNd+15C1lzad3a5D yGj9S/9PKgDBT7gkDLZL9A2TMu58ONms6xlFjC8NQgaayeUI2E7v1/vngBZrlR925hgH hL9j5GLtZ0kuzvbEBgKbBqYzO4msXIUmVKWDfbomb5U6t3jSa25OZouUhxDSy+hqPdO9 YiBA== X-Received: by 10.68.68.131 with SMTP id w3mr515541pbt.93.1412273420249; Thu, 02 Oct 2014 11:10:20 -0700 (PDT) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id b2sm2427862pbu.42.2014.10.02.11.10.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 11:10:19 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8E14869A-049B-4BBA-BE51-714AD202F191@gmail.com> X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: Need help debugging yacc test failure in CURRENT Date: Thu, 2 Oct 2014 11:10:19 -0700 To: Julio Merino Cc: Craig Rodrigues , Baptiste Daroussin , freebsd-current Current , "freebsd-testing@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 18:10:21 -0000 > On Oct 2, 2014, at 10:56, Julio Merino wrote: >=20 >> On Thu, Oct 2, 2014 at 5:23 AM, Craig Rodrigues wro= te: >> Hi, >>=20 >> I have managed to eliminate all the test failures from /usr/tests in CURR= ENT >> except for one failure. See: >>=20 >> https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/8/testReport/= >>=20 >> I can reproduce the failure by doing the following: >>=20 >> mkdir /tmp/x >> cd /tmp/x >> /usr/tests/usr.bin/yacc/yacc_tests usr.bin.yacc.yacc_tests.main >>=20 >> I then get a core file: /tmp/x/test/yacc.core >>=20 >> Can someone help debug and fix this? >=20 > What you'd do until someone fixes the yacc bug is file a PR for this > crash and then mark the test as "expected failure" (or TODO in TAP > terms). There already is a bug (look or bugs I filed related to yacc). Someone broke= behavior in the kernel or libc that yacc depends on.= From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 18:14:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3336A570; Thu, 2 Oct 2014 18:14:20 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E37D3B74; Thu, 2 Oct 2014 18:14:19 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id eu11so3085771pac.28 for ; Thu, 02 Oct 2014 11:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=QWQ8L25jEUSh/OJsFH/urv+76F/w2C0VfIjoHg4shr0=; b=xwZbSQfzMqNMNv3Xo3ekMcyBpqZLjOpL9uvSJ4V6en+0bBh5wxeW0+Spls5IJ6KYTA 1IyB4kSoTYMWbO1Y+sK7XUaoGtTvJt8dWl9HnKseasjdUTDeLjle5glfSTO259PFJ6dn JTN74HVc8uaexae/XKjsOxi+3n7LcFoE66/eXW6xJK9fYT4ix4WXaHXC88nr7/gGqitE eX2ORB3AoUmSXUOUH+PpLsqcnrLoH6dXmWo3d2Qspt6a4oIHmf3v+yfV60gvO2287xXV OQZqTrA2lZ5xpQIX74dsdoFddANM7OfpQrzsj1aGyyVlqKX3sJQPfCG+3drRIAaVBFDb WSDA== X-Received: by 10.69.31.1 with SMTP id ki1mr782485pbd.100.1412273657998; Thu, 02 Oct 2014 11:14:17 -0700 (PDT) Received: from [192.168.20.11] (c-98-247-240-204.hsd1.wa.comcast.net. [98.247.240.204]) by mx.google.com with ESMTPSA id ot8sm4438660pbc.1.2014.10.02.11.14.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 11:14:17 -0700 (PDT) References: <8E14869A-049B-4BBA-BE51-714AD202F191@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <8E14869A-049B-4BBA-BE51-714AD202F191@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3B9D64BE-9982-4334-B20B-E316A8361466@gmail.com> X-Mailer: iPhone Mail (11D257) From: Garrett Cooper Subject: Re: Need help debugging yacc test failure in CURRENT Date: Thu, 2 Oct 2014 11:14:17 -0700 To: Julio Merino Cc: Craig Rodrigues , Baptiste Daroussin , freebsd-current Current , "freebsd-testing@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 18:14:20 -0000 > On Oct 2, 2014, at 11:10, Garrett Cooper wrote: >=20 >=20 >>> On Oct 2, 2014, at 10:56, Julio Merino wrote: >>>=20 >>> On Thu, Oct 2, 2014 at 5:23 AM, Craig Rodrigues wr= ote: >>> Hi, >>>=20 >>> I have managed to eliminate all the test failures from /usr/tests in CUR= RENT >>> except for one failure. See: >>>=20 >>> https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/8/testReport= / >>>=20 >>> I can reproduce the failure by doing the following: >>>=20 >>> mkdir /tmp/x >>> cd /tmp/x >>> /usr/tests/usr.bin/yacc/yacc_tests usr.bin.yacc.yacc_tests.main >>>=20 >>> I then get a core file: /tmp/x/test/yacc.core >>>=20 >>> Can someone help debug and fix this? >>=20 >> What you'd do until someone fixes the yacc bug is file a PR for this >> crash and then mark the test as "expected failure" (or TODO in TAP >> terms). >=20 > There already is a bug (look or bugs I filed related to yacc). Someone bro= ke behavior in the kernel or libc that yacc depends on. Let me rephrase that. Using an older atf/kyua didn't repro the bug, so it's p= robably atf/kyua= From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 19:35:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7473D31; Thu, 2 Oct 2014 19:35:19 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A635374C; Thu, 2 Oct 2014 19:35:19 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3F5A0B93C; Thu, 2 Oct 2014 15:35:18 -0400 (EDT) From: John Baldwin To: Adrian Chadd Subject: Re: [PATCH] Fix OACTIVE for an(4) Date: Thu, 2 Oct 2014 13:40:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <2113392.UOaBFTpimf@ralph.baldwin.cx> <201410021116.27583.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201410021340.22447.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 02 Oct 2014 15:35:18 -0400 (EDT) Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 19:35:20 -0000 On Thursday, October 02, 2014 1:24:22 pm Adrian Chadd wrote: > On 2 October 2014 08:16, John Baldwin wrote: > > On Wednesday, October 01, 2014 2:58:38 pm Adrian Chadd wrote: > >> Hi, > >> > >> On 1 October 2014 07:14, John Baldwin wrote: > >> > This small patch correctly sets OACTIVE when an(4) gets backed up. Right > > now > >> > I believe it will never set the flag. It is only an optimization, it > > should > >> > not affect correctness. > >> > > >> > Index: an/if_an.c > >> > =================================================================== > >> > --- an/if_an.c (revision 270968) > >> > +++ an/if_an.c (working copy) > >> > @@ -2906,11 +2906,11 @@ > >> > CSR_WRITE_2(sc, AN_INT_EN(sc->mpi350), AN_INTRS(sc- > >>mpi350)); > >> > } > >> > > >> > - if (m0 != NULL) > >> > + if (sc->an_rdata.an_tx_prod != idx) { > >> > ifp->if_drv_flags |= IFF_DRV_OACTIVE; > >> > + sc->an_rdata.an_tx_prod = idx; > >> > + } > >> > > >> > - sc->an_rdata.an_tx_prod = idx; > >> > - > >> > return; > >> > } > >> > >> I haven't looked at the rest of the driver; is everything else around > >> OACTIVE locked correctly and consistently? > > > > As well as OACTIVE is for any other driver. > > > >> There's no single-entry into if_start(). It can be called from > >> multiple paths at the same time. > > > > Yes, I know. However, this bug is more that it will never set OACTIVE > > currently (m0 is always set to NULL before it gets to this point). > > > > This code in its stats timer is also dubious: > > > > /* Don't do this while we're transmitting */ > > if (ifp->if_drv_flags & IFF_DRV_OACTIVE) { > > callout_reset(&sc->an_stat_ch, hz, an_stats_update, sc); > > return; > > } > > > > sc->an_stats.an_len = sizeof(struct an_ltv_stats); > > sc->an_stats.an_type = AN_RID_32BITS_CUM; > > if (an_read_record(sc, (struct an_ltv_gen *)&sc->an_stats.an_len)) > > return; > > > > callout_reset(&sc->an_stat_ch, hz, an_stats_update, sc); > > > > First, the callout_reset() can just be moved earlier. > > > > Second, OACTIVE doesn't mean that anything is transmitting, it means the ring > > is full (at least in terms of how all other drivers use it). > > yes, but if you don't absolutely handle it in a race-free situation, > you end up never having if_start() called. > > IFQ_HANDOFF() -> IFQ_HANDOFF_ADJ() -> enqueue, then if it worked AND > OACTIVE==0, call if_start() > > Then you hit the stupid situation where OACTIVE was set just long > enough for the queue to fill up without calling if_start(), then once > it's filled if_start() won't ever be called from the transmitter > context. It has to be called from the completion context or the > receive context. Or, well, anywhere. > > All of that stuff needs to die. Yes, but this is true of all if_start-using drivers currently, and it cannot be fixed in the drivers themselves. It is orthogonal to whether or not an(4) correctly sets OACTIVE. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 20:55:11 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4085EA7; Thu, 2 Oct 2014 20:55:11 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE189F8A; Thu, 2 Oct 2014 20:55:10 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id rl12so3324874iec.31 for ; Thu, 02 Oct 2014 13:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yCqemzT6P/tl0kYHABZTeAmYWyowto6vtkD3/nMSqP8=; b=v3BBxTKMpljvIL0v1PtojfsIZJFj6BNMVTuekXtrlXJjAHu8dHxhktXHS0U1rYt8k9 I7Umo+2FsSdYi0h0FoQqKYwA8l1xbDx6ejtvPr4+MoSSTUEvrenGojupMVX92klATyLF wCAA8GkQseP+rjKRGoEgBItjsa8BF2B8ap3VsGkI/kqLtQ7ejvg+tt11sSytPC0DMza4 EjDhhh+E0P9LnXk//l0zW2E2CP4t64QFns5HaNNesFvXh/NRDHhGuFEbg84REm8HUyyJ Y8yvROedfKqcarrwlOHo/VZVUba2iOQesSvYPcit7eITLgjb8PPqKVI1HqKa/WTSlWK+ iBTQ== MIME-Version: 1.0 X-Received: by 10.42.207.131 with SMTP id fy3mr8160117icb.67.1412283310316; Thu, 02 Oct 2014 13:55:10 -0700 (PDT) Received: by 10.50.227.42 with HTTP; Thu, 2 Oct 2014 13:55:10 -0700 (PDT) In-Reply-To: <3B9D64BE-9982-4334-B20B-E316A8361466@gmail.com> References: <8E14869A-049B-4BBA-BE51-714AD202F191@gmail.com> <3B9D64BE-9982-4334-B20B-E316A8361466@gmail.com> Date: Thu, 2 Oct 2014 13:55:10 -0700 Message-ID: Subject: Re: Need help debugging yacc test failure in CURRENT From: NGie Cooper To: Julio Merino Content-Type: text/plain; charset=UTF-8 Cc: Craig Rodrigues , Baptiste Daroussin , freebsd-current Current , "freebsd-testing@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 20:55:11 -0000 On Thu, Oct 2, 2014 at 11:14 AM, Garrett Cooper wrote: ... > Let me rephrase that. Using an older atf/kyua didn't repro the bug, so it's probably atf/kyua Here's the bug I was referring to: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193499 (was replying on my phone earlier). Thanks! From owner-freebsd-current@FreeBSD.ORG Thu Oct 2 22:07:19 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 146FABDC; Thu, 2 Oct 2014 22:07:19 +0000 (UTC) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 5F88599B; Thu, 2 Oct 2014 22:07:18 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 084B67300A; Fri, 3 Oct 2014 00:12:23 +0200 (CEST) Date: Fri, 3 Oct 2014 00:12:23 +0200 From: Luigi Rizzo To: current@freebsd.org, delphij@freebsd.org, net@freebsd.org Subject: adding netmap support to libpcap in FreeBSD Message-ID: <20141002221223.GA37059@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 22:07:19 -0000 I want to bring netmap support into our libpcap. The patch is attached, and as you can see changes are trivial, with the new methods contained in a new file pcap-netmap.c I would love to upstream this to the libpcap project (I even have the necessary configure* patches, see code.google.com/p/netmap-libpcap), but I don't see that happening soon: when I tried last winter there was hardly any interest, and then a bikeshed on the absence of a findalldevs method (which i cannot provide as the set would be infinite, unlike my patience :) So for the time being I plan to put the new source file pcap-netmap.c into lib/libpcap instead of contrib/libpcap . Let me know if you have objections. cheers luigi Index: contrib/libpcap/inet.c =================================================================== --- contrib/libpcap/inet.c (revision 272410) +++ contrib/libpcap/inet.c (working copy) @@ -737,6 +737,10 @@ #ifdef PCAP_SUPPORT_USB || strstr(device, "usbmon") != NULL #endif +#ifdef PCAP_SUPPORT_NETMAP + || !strncmp(device, "netmap:", 7) + || !strncmp(device, "vale", 4) +#endif #ifdef HAVE_SNF_API || strstr(device, "snf") != NULL #endif Index: contrib/libpcap/pcap.c =================================================================== --- contrib/libpcap/pcap.c (revision 272410) +++ contrib/libpcap/pcap.c (working copy) @@ -106,6 +106,10 @@ #include "pcap-netfilter-linux.h" #endif +#ifdef PCAP_SUPPORT_NETMAP +pcap_t* pcap_netmap_create(const char *device, char *ebuf, int *is_ours); +#endif + int pcap_not_initialized(pcap_t *pcap) { @@ -301,6 +305,9 @@ int (*findalldevs_op)(pcap_if_t **, char *); pcap_t *(*create_op)(const char *, char *, int *); } capture_source_types[] = { +#ifdef PCAP_SUPPORT_NETMAP + { NULL, pcap_netmap_create }, +#endif #ifdef HAVE_DAG_API { dag_findalldevs, dag_create }, #endif Index: lib/libpcap/Makefile =================================================================== --- lib/libpcap/Makefile (revision 272410) +++ lib/libpcap/Makefile (working copy) @@ -7,6 +7,7 @@ LIB= pcap SRCS= grammar.y tokdefs.h version.h pcap-bpf.c \ + pcap-netmap.c \ pcap.c pcap-common.c inet.c fad-getad.c gencode.c optimize.c nametoaddr.c \ etherent.c savefile.c bpf_filter.c bpf_image.c bpf_dump.c \ scanner.l sf-pcap.c sf-pcap-ng.c version.c Index: lib/libpcap/config.h =================================================================== --- lib/libpcap/config.h (revision 272410) +++ lib/libpcap/config.h (working copy) @@ -271,6 +271,9 @@ /* target host supports USB sniffing */ /* #undef PCAP_SUPPORT_USB */ +/* target host supports netmap */ +#define PCAP_SUPPORT_NETMAP 1 + /* include ACN support */ /* #undef SITA */ Index: lib/libpcap/pcap-netmap.c =================================================================== --- /dev/null 2014-10-02 23:33:00.000000000 +0200 +++ lib/libpcap/pcap-netmap.c 2014-10-02 23:37:33.000000000 +0200 @@ -0,0 +1,265 @@ +/* + * Copyright (C) 2014 Luigi Rizzo. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``S IS''AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include +#include +#include +#include +#include +#include + +#define NETMAP_WITH_LIBS +#include + +#include "pcap-int.h" + +/* + * This code is meant to build also on older versions of libpcap. + * + * older libpcap miss p->priv, use p->md.device instead (and allocate). + * Also opt.timeout was in md.timeout before. + * Use #define PCAP_IF_UP to discriminate + */ +#ifdef PCAP_IF_UP +#define NM_PRIV(p) ((struct pcap_netmap *)(p->priv)) +#define the_timeout opt.timeout +#else +#define HAVE_NO_PRIV +#define NM_PRIV(p) ((struct pcap_netmap *)(p->md.device)) +#define SET_PRIV(p, x) p->md.device = (void *)x +#define the_timeout md.timeout +#endif + +#if defined (linux) +/* On FreeBSD we use IFF_PPROMISC which is in ifr_flagshigh. + * remap to IFF_PROMISC on linux + */ +#define IFF_PPROMISC IFF_PROMISC +#define ifr_flagshigh ifr_flags +#endif /* linux */ + +struct pcap_netmap { + struct nm_desc *d; /* pointer returned by nm_open() */ + pcap_handler cb; /* callback and argument */ + u_char *cb_arg; + int must_clear_promisc; /* flag */ + uint64_t rx_pkts; /* # of pkts received before the filter */ +}; + +static int +pcap_netmap_stats(pcap_t *p, struct pcap_stat *ps) +{ + struct pcap_netmap *pn = NM_PRIV(p); + + ps->ps_recv = pn->rx_pkts; + ps->ps_drop = 0; + ps->ps_ifdrop = 0; + return 0; +} + +static void +pcap_netmap_filter(u_char *arg, struct pcap_pkthdr *h, const u_char *buf) +{ + pcap_t *p = (pcap_t *)arg; + struct pcap_netmap *pn = NM_PRIV(p); + + ++pn->rx_pkts; + if (bpf_filter(p->fcode.bf_insns, buf, h->len, h->caplen)) + pn->cb(pn->cb_arg, h, buf); +} + +static int +pcap_netmap_dispatch(pcap_t *p, int cnt, pcap_handler cb, u_char *user) +{ + int ret; + struct pcap_netmap *pn = NM_PRIV(p); + struct nm_desc *d = pn->d; + struct pollfd pfd = { .fd = p->fd, .events = POLLIN, .revents = 0 }; + + pn->cb = cb; + pn->cb_arg = user; + + for (;;) { + if (p->break_loop) { + p->break_loop = 0; + return PCAP_ERROR_BREAK; + } + /* nm_dispatch won't run forever */ + + ret = nm_dispatch((void *)d, cnt, (void *)pcap_netmap_filter, (void *)p); + if (ret != 0) + break; + errno = 0; + ret = poll(&pfd, 1, p->the_timeout); + } + return ret; +} + +/* XXX need to check the NIOCTXSYNC/poll */ +static int +pcap_netmap_inject(pcap_t *p, const void *buf, size_t size) +{ + struct nm_desc *d = NM_PRIV(p)->d; + + return nm_inject(d, buf, size); +} + +static int +pcap_netmap_ioctl(pcap_t *p, u_long what, uint32_t *if_flags) +{ + struct pcap_netmap *pn = NM_PRIV(p); + struct nm_desc *d = pn->d; + struct ifreq ifr; + int error, fd = d->fd; + +#ifdef linux + fd = socket(AF_INET, SOCK_DGRAM, 0); + if (fd < 0) { + fprintf(stderr, "Error: cannot get device control socket.\n"); + return -1; + } +#endif /* linux */ + bzero(&ifr, sizeof(ifr)); + strncpy(ifr.ifr_name, d->req.nr_name, sizeof(ifr.ifr_name)); + switch (what) { + case SIOCSIFFLAGS: + ifr.ifr_flags = *if_flags; + ifr.ifr_flagshigh = *if_flags >> 16; + break; + } + error = ioctl(fd, what, &ifr); + if (error) + return -1; + switch (what) { + case SIOCGIFFLAGS: + *if_flags = ifr.ifr_flags | (ifr.ifr_flagshigh << 16); + } + return 0; +} + +static void +pcap_netmap_close(pcap_t *p) +{ + struct pcap_netmap *pn = NM_PRIV(p); + struct nm_desc *d = pn->d; + uint32_t if_flags = 0; + + if (pn->must_clear_promisc) { + pcap_netmap_ioctl(p, SIOCGIFFLAGS, &if_flags); /* fetch flags */ + if (if_flags & IFF_PPROMISC) { + if_flags &= ~IFF_PPROMISC; + pcap_netmap_ioctl(p, SIOCSIFFLAGS, &if_flags); + } + } + nm_close(d); +#ifdef HAVE_NO_PRIV + free(pn); + SET_PRIV(p, NULL); // unnecessary +#endif + pcap_cleanup_live_common(p); +} + +static int +pcap_netmap_activate(pcap_t *p) +{ + struct pcap_netmap *pn = NM_PRIV(p); + struct nm_desc *d = nm_open(p->opt.source, NULL, 0, NULL); + uint32_t if_flags = 0; + + if (d == NULL) { + snprintf(p->errbuf, PCAP_ERRBUF_SIZE, + "netmap open: cannot access %s: %s\n", + p->opt.source, pcap_strerror(errno)); +#ifdef HAVE_NO_PRIV + free(pn); + SET_PRIV(p, NULL); // unnecessary +#endif + pcap_cleanup_live_common(p); + return (PCAP_ERROR); + } + if (0) + fprintf(stderr, "%s device %s priv %p fd %d ports %d..%d\n", + __FUNCTION__, p->opt.source, d, d->fd, + d->first_rx_ring, d->last_rx_ring); + pn->d = d; + p->fd = d->fd; + if (p->opt.promisc && !(d->req.nr_ringid & NETMAP_SW_RING)) { + pcap_netmap_ioctl(p, SIOCGIFFLAGS, &if_flags); /* fetch flags */ + if (!(if_flags & IFF_PPROMISC)) { + pn->must_clear_promisc = 1; + if_flags |= IFF_PPROMISC; + pcap_netmap_ioctl(p, SIOCSIFFLAGS, &if_flags); + } + } + p->linktype = DLT_EN10MB; + p->selectable_fd = p->fd; + p->read_op = pcap_netmap_dispatch; + p->inject_op = pcap_netmap_inject, + p->setfilter_op = install_bpf_program; + p->setdirection_op = NULL; + p->set_datalink_op = NULL; + p->getnonblock_op = pcap_getnonblock_fd; + p->setnonblock_op = pcap_setnonblock_fd; + p->stats_op = pcap_netmap_stats; + p->cleanup_op = pcap_netmap_close; + + return (0); +} + +pcap_t * +pcap_netmap_create(const char *device, char *ebuf, int *is_ours) +{ + pcap_t *p; + + *is_ours = (!strncmp(device, "netmap:", 7) || !strncmp(device, "vale", 4)); + if (! *is_ours) + return NULL; +#ifdef HAVE_NO_PRIV + { + void *pn = calloc(1, sizeof(struct pcap_netmap)); + if (pn == NULL) + return NULL; + p = pcap_create_common(device, ebuf); + if (p == NULL) { + free(pn); + return NULL; + } + SET_PRIV(p, pn); + } +#else + p = pcap_create_common(device, ebuf, sizeof (struct pcap_netmap)); + if (p == NULL) + return (NULL); +#endif + p->activate_op = pcap_netmap_activate; + return (p); +} From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 00:50:58 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A3D1FA9; Fri, 3 Oct 2014 00:50:58 +0000 (UTC) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd01.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 260F0AFF; Fri, 3 Oct 2014 00:50:57 +0000 (UTC) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s930omWm032148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Oct 2014 20:50:49 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s930omWm032148 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1412297449; bh=22QYeLWUhxVH4tZsDtpodUqW+Kw=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=NZyGhX2aI/w5wCsOsSMKi4uIZ5rE/cA1iS1YZMi4kQ3KcY3n96kCnRbjrvdKZzEq9 KSgp1QYuSFHY6xJIdizTrow+71TbC+7rdja0Wzk33J+0YuZ0C5tSe8NKvXsW+S0zzI YdoHNNYBlqixg4OXi6EaICAacOB0Xa6SLhHt/dvE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s930omWm032148 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd02.lss.emc.com (RSA Interceptor); Thu, 2 Oct 2014 20:50:16 -0400 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s930oWwB028280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Oct 2014 20:50:32 -0400 Received: from mx34a.corp.emc.com ([169.254.1.46]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Thu, 2 Oct 2014 20:50:32 -0400 From: "O'Connor, Daniel" To: "O'Connor, Daniel" Date: Thu, 2 Oct 2014 20:50:30 -0400 Subject: Re: What do you use for kernel debugging? Thread-Topic: What do you use for kernel debugging? Thread-Index: Ac/epAhuw8pAITpYSzukJWAVWy1m9Q== Message-ID: <18C885A5-5162-4868-8A1A-DDBC7A92CCF5@emc.com> References: <20140928071641.M7664@beckpeccoz.com> <20140929003358.M78145@aoek.com> <542AC1C8.9030101@freebsd.org> <90CE0701-F1CB-41DF-B3D2-87816DC03DF9@emc.com> <3718AED6-9514-49F9-AF11-B47CFAF01161@emc.com> In-Reply-To: <3718AED6-9514-49F9-AF11-B47CFAF01161@emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: DLP to NYP, DLM_1, public X-Mailman-Approved-At: Fri, 03 Oct 2014 01:14:40 +0000 Cc: Adrian Chadd , =?Windows-1252?Q?Jos=E9_P=E9rez_Arauzo?= , FreeBSD Current , Benjamin Kaduk , Garrett Cooper X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 00:50:58 -0000 On 1 Oct 2014, at 15:54, O'Connor, Daniel wrote: > On 1 Oct 2014, at 14:33, Adrian Chadd wrote: >> There's also something for XHCI. >=20 > So I see.. >=20 > Section 7.6 in here has details.. > http://www.intel.com.au/content/dam/www/public/us/en/documents/technical-= specifications/extensible-host-controler-interface-usb-xhci.pdf >=20 > Interestingly unlike the EHCI version it does not require hardware betwee= n the debugger and debugee, only a special cable. (see http://msdn.microsof= t.com/en-us/library/windows/hardware/hh439372(v=3Dvs.85).aspx) I wrote a quick program to dump xHCI extended capabilities https://gist.git= hub.com/DanielO/c42819ae69a1f680039a Run pciconf -lb and look for the base value for xhciX then run the command = with that like so.. xhci0@pci0:3:0:0: class=3D0x0c0330 card=3D0x077815ad chip=3D0x077815ad rev= =3D0x00 hdr=3D0x00 bar [10] =3D type Memory, range 64, base 0xfd4c0000, size 131072, ena= bled root@foo:~ # ./xhcicap 0xfd4c0000 HCCPARAMS1 =3D> 0x0388f283 xECP (0xfd4c0e20) =3D> ID 2 (Supported protocol) Specific 0x0300 xECP (0xfd4c0e23) =3D> ID 3 (Extended PM) Specific 0x4253 (this is a VMWare Fusion guest with USB3 enabled) I ran it on Gigabyte Z77-D3H board (only real hardware I had handy with USB= 3) which has 2 USB3 controllers - one on the Intel chipset, the other an Et= ron EJ168. It shows.. Intel.. HCCPARAMS1 =3D> 0x20007181 xECP (0xf7f08000) =3D> ID 2 (Supported protocol) Specific 0x200 xECP (0xf7f08008) =3D> ID 1 (Legacy support) Specific 0x3001 Etron.. HCCPARAMS1 =3D> 0x040050af xECP (0xf7c01000) =3D> ID 1 (Legacy support) Specific 0x0000 Neither support debugging (and according to the spec the later is broken as= it is supposed to have at least one =91supported protocol=92 entry). Regards, Daniel O=92Connor Senior Software Engineer Isilon Platforms Team From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 08:13:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 172E2A19; Fri, 3 Oct 2014 08:13:31 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DBF1846; Fri, 3 Oct 2014 08:13:30 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s938DSAd095942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Oct 2014 12:13:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s938DSRZ095941; Fri, 3 Oct 2014 12:13:28 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 3 Oct 2014 12:13:28 +0400 From: Gleb Smirnoff To: John Baldwin Subject: Re: [PATCH] Fix OACTIVE for an(4) Message-ID: <20141003081328.GZ73266@FreeBSD.org> References: <2113392.UOaBFTpimf@ralph.baldwin.cx> <201410021116.27583.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201410021116.27583.jhb@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 08:13:31 -0000 On Thu, Oct 02, 2014 at 11:16:27AM -0400, John Baldwin wrote: J> > I haven't looked at the rest of the driver; is everything else around J> > OACTIVE locked correctly and consistently? J> J> As well as OACTIVE is for any other driver. Let me jump into this topic and discuss the if_drv_flags :) It seems to me that this in general was a wrong concept, both IFF_DRV_OACTIVE and IFF_DRV_RUNNING. The internal state of the driver can be known only to the driver itself and should be stored in the softc, covered with internal lock. There is simply no way to racelessly tell the state from the outside, without obtaining driver lock. In my ifnet plans I am considering to remove if_drv_flags. Can anyone convince me that this is a wrong idea and they should be kept? -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 08:25:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4766EF0D for ; Fri, 3 Oct 2014 08:25:44 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id C8ED3968 for ; Fri, 3 Oct 2014 08:25:42 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id s938PZ9M024885 for ; Fri, 3 Oct 2014 17:25:35 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili17) with ESMTP id s938PZA24970 for ; Fri, 3 Oct 2014 17:25:35 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi15) id s938PZCZ005771; Fri, 3 Oct 2014 17:25:35 +0900 Received: from localhost by lomi15.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s938PZdi005751; Fri, 3 Oct 2014 17:25:35 +0900 Date: Fri, 03 Oct 2014 17:25:33 +0900 (JST) Message-Id: <20141003.172533.863334695746935674.okuno.kohji@jp.panasonic.com> To: freebsd-current@freebsd.org Subject: About pmap_mapdev() & pmap_unmapdev() From: Kohji Okuno Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 08:25:44 -0000 Hi, At least in i386 && 9-stable, when we call pmap_mapdev() and pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased incorrectly. pmap_mapdev_attr()->pmap_kenter_attr(): In this path, kernel_pmap.pm_stats.resident_count is not increlmented. pmap_unmapdev()->kmem_free(kernel_map)->vm_map_remove()->pmap_remove(): But, in this path, kernel_pmap.pm_stats.resident_count is decreased in pmap_remove_pte(). While I called pmap_mapdev() and pmap_unmapdev() repeatedly and kernel_pmap.pm_stats.resident_count became `0', since pmap_remove() returned without removing ptes, I encountered various kernel panics. And, when I enabled INVARIANTS, I looked the following panic message. panic: vm_page_free_toq: freeing mapped page 0xXXXXXXXX. I think, I should change the following. What do you think about this? diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c index 2adc6f8..a0998e8 100644 --- a/sys/i386/i386/pmap.c +++ b/sys/i386/i386/pmap.c @@ -5061,6 +5061,7 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode) { vm_offset_t va, offset; vm_size_t tmpsize; + int kmem_allocated = 0; offset = pa & PAGE_MASK; size = roundup(offset + size, PAGE_SIZE); @@ -5068,13 +5069,18 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode) if (pa < KERNLOAD && pa + size <= KERNLOAD) va = KERNBASE + pa; - else + else { va = kmem_alloc_nofault(kernel_map, size); + kmem_allocated = 1; + } if (!va) panic("pmap_mapdev: Couldn't alloc kernel virtual memory"); - for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) + for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) { pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode); + if (kmem_allocated) + kernel_pmap.pm_stats.resident_count++; + } pmap_invalidate_range(kernel_pmap, va, va + tmpsize); pmap_invalidate_cache_range(va, va + size); return ((void *)(va + offset)); From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 08:29:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 786DC1A6; Fri, 3 Oct 2014 08:29:54 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B368A9A5; Fri, 3 Oct 2014 08:29:53 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id l18so856947wgh.29 for ; Fri, 03 Oct 2014 01:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mhfItokrNdFXIVIoyYsI+hEd0lTfOLqEv48PlOu6KBc=; b=1A/5ewotzL0wc6u6fnrIqSYPRLYXIsbS8jax/RQs5YWFWo8FYqFRdL1XLOTQHgGTal VwgsK+Kx2oKl0ltZ3CUOZ9EgjW4UESd0kU7U7HUoDyGGbwRnMiSwdpcCG6IQmMJ1gV6P de+BlnIAXjtPbRgPp5qkJjQo9tj0ZD5wQAG2QPmFIpvtpEVp9X0Gu6F8kBPTihIbfdqv M+48pP0CBzb3aV1dj01+iyYLgj22yLoMjG9jZeEcHQJbJIvNwjqXpopl3Wy10V+7ldei MvWsNn7ZrBGn7RpBp0SHnAprBEMmdeFQzbHXnTdfNnVGh4ICTuVK3ER6awvI6QWrlKVT ZD3w== MIME-Version: 1.0 X-Received: by 10.180.107.100 with SMTP id hb4mr10313043wib.59.1412324991891; Fri, 03 Oct 2014 01:29:51 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 3 Oct 2014 01:29:51 -0700 (PDT) In-Reply-To: <20141003081328.GZ73266@FreeBSD.org> References: <2113392.UOaBFTpimf@ralph.baldwin.cx> <201410021116.27583.jhb@freebsd.org> <20141003081328.GZ73266@FreeBSD.org> Date: Fri, 3 Oct 2014 01:29:51 -0700 X-Google-Sender-Auth: JwxfQgqeac_SvJazb2UIuXj7ObM Message-ID: Subject: Re: [PATCH] Fix OACTIVE for an(4) From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 08:29:54 -0000 Having them as flags that can be seen from external is good for diagnostics. Having external things change behaviour (like queuing packets and running if_start) is error prone. It isn't a wrong concept. Computers just grew up a bit more. -a On 3 October 2014 01:13, Gleb Smirnoff wrote: > On Thu, Oct 02, 2014 at 11:16:27AM -0400, John Baldwin wrote: > J> > I haven't looked at the rest of the driver; is everything else around > J> > OACTIVE locked correctly and consistently? > J> > J> As well as OACTIVE is for any other driver. > > Let me jump into this topic and discuss the if_drv_flags :) > > It seems to me that this in general was a wrong concept, both > IFF_DRV_OACTIVE and IFF_DRV_RUNNING. The internal state of > the driver can be known only to the driver itself and should > be stored in the softc, covered with internal lock. > > There is simply no way to racelessly tell the state from the > outside, without obtaining driver lock. > > In my ifnet plans I am considering to remove if_drv_flags. > Can anyone convince me that this is a wrong idea and they > should be kept? > > -- > Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 09:30:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C46B3C2D for ; Fri, 3 Oct 2014 09:30:40 +0000 (UTC) Received: from frv190.fwdcdn.com (frv190.fwdcdn.com [212.42.77.190]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82294DD for ; Fri, 3 Oct 2014 09:30:40 +0000 (UTC) Received: from [10.10.2.23] (helo=frv198.fwdcdn.com) by frv190.fwdcdn.com with esmtp ID 1XZyxR-000MAb-Qv for freebsd-current@freebsd.org; Fri, 03 Oct 2014 12:15:25 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:To:Subject:From:Date; bh=GgqKkRlY/jVZaJ/yvn58ndibhqVongBQhTWdRrRn2sc=; b=VYbRjzK6KvP+9Q5kuZCv3fIWqmQ2IYC1M/dx1z03vHGBxgw4fgrlmbPk9NlZ8n5Xs4MAmZoMos3AkLpexDI6ccZiH0dfkhxeFHDt9akEysZLiLevOcsmN/Gm8YotzP4D+pkR/55FoPCKgDkHBPfjw7O4eue6jrJuKt4h7TvQXXE=; Received: from [10.10.10.45] (helo=frv45.fwdcdn.com) by frv198.fwdcdn.com with smtp ID 1XZyxE-000LcY-NM for freebsd-current@freebsd.org; Fri, 03 Oct 2014 12:15:12 +0300 Date: Fri, 03 Oct 2014 12:15:12 +0300 From: Vladimir Sharun Subject: Re[2]: make installworld for i386 fails on Kyuafile To: FreeBSD CURRENT X-Mailer: mail.ukr.net 5.0 Message-Id: <1412327616.905769810.dqby8t7x@frv45.fwdcdn.com> In-Reply-To: References: <14666.10975.bm@smtp118.sbc.mail.ne1.yahoo.com> MIME-Version: 1.0 Received: from atz@ukr.net by frv45.fwdcdn.com; Fri, 03 Oct 2014 12:15:12 +0300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 09:30:40 -0000 Hello, Seems this issue raised again in r272469, at least today and yesterday installworld fails. Last time was few minutes ago with the revision shown. > > install: /usr/tests/lib/libproc/Kyuafile: No such file or directory > > Fixed in r271950. Problem introduced in r271937 which seems to have > missed part of the change sent out for review in D710. From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 12:57:44 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04179267 for ; Fri, 3 Oct 2014 12:57:44 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2EF497B for ; Fri, 3 Oct 2014 12:57:43 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1Xa2N6-001cuP-Kd>; Fri, 03 Oct 2014 14:54:08 +0200 Received: from g225107160.adsl.alicedsl.de ([92.225.107.160] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1Xa2N6-003LvP-IS>; Fri, 03 Oct 2014 14:54:08 +0200 Date: Fri, 3 Oct 2014 14:54:03 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT: ath0: stuck beacon; resetting (bmiss count 4) Message-ID: <20141003145403.704e85be.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/6K1RY8fT6d/EQMK9sl4k+_n"; protocol="application/pgp-signature" X-Originating-IP: 92.225.107.160 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 12:57:44 -0000 --Sig_/6K1RY8fT6d/EQMK9sl4k+_n Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Since a couple of days I get this weird console-and-log-spamming message: ath0: stuck beacon; resetting (bmiss count 4) The machine in question is running the most recent CURRENT right now: FreeBSD 11.0-CURRENT #2 r272471: Fri Oct 3 13:03:58 CEST 2014 amd64 and the box acts as a gateway with WiFi access point via hostapd and this W= iFi hardware: [...] ath0: mem 0xf7e00000-0xf7e0ffff irq 16 at device 0.0 on pci1 ath0: [HT] enabling HT modes ath0: [HT] enabling short-GI in 20MHz mode ath0: [HT] 1 stream STBC receive enabled ath0: [HT] 1 stream STBC transmit enabled ath0: [HT] 2 RX streams; 2 TX streams [...] ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 What is this and how can I get rid of it? Regards, Oliver --Sig_/6K1RY8fT6d/EQMK9sl4k+_n Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJULpxwAAoJEOgBcD7A/5N8byUH/iWp2XMmCsBy5QbBZzeN6TnN RcVjbaDcNehZ5U6526vGDfyns69rj3irPVo2rJDjHIH1hAozXx1RWFuFOE99CjPp 2SRFkgImCTUHgruUi6WnJFyUXNbKlRg5snvm4BSz3lYsDN19wVdaNsut5VBHIPvQ a0kVnQ+4vH3pEMh8pc+mQ/Ptkwdno7OOzNHADd6O38mSq5p2sA7uwMneSR+uCTDR fQsXilsWnQJ+8SvVPfXpw06pG4GGyJpfqVhf3iVo6dTeDTWuzEidkjErnshT7PFU llKWalXOxbF9voQAplJfDpLTyH+ojP1GbbHr2uaC6Jmmz5qVEnrSdojwp/vShsM= =KFCF -----END PGP SIGNATURE----- --Sig_/6K1RY8fT6d/EQMK9sl4k+_n-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 13:14:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C390F793; Fri, 3 Oct 2014 13:14:56 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F24AB87; Fri, 3 Oct 2014 13:14:56 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1Xa2hC-001gdF-GJ>; Fri, 03 Oct 2014 15:14:54 +0200 Received: from g225107160.adsl.alicedsl.de ([92.225.107.160] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1Xa2hC-003NEc-EO>; Fri, 03 Oct 2014 15:14:54 +0200 Date: Fri, 3 Oct 2014 15:14:53 +0200 From: "O. Hartmann" To: FreeBSD CURRENT , FreeBSD Questions Subject: [CURRENT] hostapd: WPA w/ EAP-TTLS or EAP-PEAP or EAP-TLS ? Message-ID: <20141003151453.620a1f2b.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/4dl7sMWzqIdduL=yCdhF.he"; protocol="application/pgp-signature" X-Originating-IP: 92.225.107.160 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 13:14:56 -0000 --Sig_/4dl7sMWzqIdduL=yCdhF.he Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Where is the support on WPA with EAP-TTLS or EAP-PEAP or EAP-TLS in hostap= d? Trying to circumvent FreeBSD's very poor documentation on the options of ho= stapd, I found lots of howtos for Linuxes of different flavours utilizing obviously the sa= me hostapd basis. But whenever I try to configure one of the above mentioned auth meth= ods for a gateway I try to configure (CURRENT, 10.1-PRE), I get an error. What is up here? Regards, Oliver --Sig_/4dl7sMWzqIdduL=yCdhF.he Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEbBAEBAgAGBQJULqFOAAoJEOgBcD7A/5N8dIEH+LsvllZa5jcrwMZJ6Jumemek kJQKDHopvzZWooxJPoTJvDMVq/PwsE5ypeBrVeU4IgRtJ27J9zz8w+bZ2nKDQm86 tfVbRFcEAGP/6g8wk6Jag51wwz2aFky4BHkpNv6KbN31vlvwyZZNrXNqPHb8aX/Z IbQptkTOVT5ya72x9dU78TcEl9MQdLotEtehaKi/PyHYZEDgApALFWmfs6gE2LCz +guHs0o3TcNzk7G12R3hbE6Fnb9vLIGJDDz65c9tzWeUECb3t7m7N7QSjvljWPoF BqtOC9P1kddbmBiBRQ7cNe+CrQoihHr2gwn/Xx1T+NofPsuDhiMJqWX9SH6WZA== =8PFU -----END PGP SIGNATURE----- --Sig_/4dl7sMWzqIdduL=yCdhF.he-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 13:24:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45D79BA9 for ; Fri, 3 Oct 2014 13:24:42 +0000 (UTC) Received: from cursor.its.uu.se (smtp-out1.uu.se [130.238.7.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9884C9C for ; Fri, 3 Oct 2014 13:24:41 +0000 (UTC) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [192.36.171.202]) by cursor.its.uu.se (Postfix) with ESMTP id 111BC310; Fri, 3 Oct 2014 15:15:57 +0200 (CEST) Received: from velox.its.uu.se (velox.its.uu.se [130.238.7.74]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s93DFuEK007053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2014 15:15:56 +0200 Received: from virgata.its.uu.se (virgata.its.uu.se [130.238.7.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by velox.its.uu.se (Postfix) with ESMTPS id 9BC6134D62; Fri, 3 Oct 2014 15:15:56 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 velox.its.uu.se 9BC6134D62 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uu.se; s=centralsmtp; t=1412342156; i=@uu.se; bh=OuYK1WK2XXbBAsaEAYsmVkKFepVXlTUz39QFTxoq4N8=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qFBQt7GKmDCNIeG9S6SSgjCicOQEbLYypfmnAc2d7DBPI22RkGQNHJabfWCsRMfyP 5OxNQn4A0ZNEHByb2gxeXcFyfMOUzICxT7g9cWcuYjDEaVvKdNYZak70rO7w0M0DnD /nC+OBJAqFmpvQNj3fAGk4CKuHphn5oCxmh8P8Rk= Received: from jubula (localhost.localdomain [127.0.0.1]) by virgata.its.uu.se (8.13.8/8.13.8) with ESMTP id s93DFsZS028611; Fri, 3 Oct 2014 15:15:56 +0200 Received: from h-197-74.a213.corp.bahnhof.se (h-197-74.a213.corp.bahnhof.se [85.24.197.74]) by webmail.uu.se (Horde Framework) with HTTP; Fri, 03 Oct 2014 15:15:54 +0200 Message-ID: <20141003151554.19434wd2pn8bwlu2@webmail.uu.se> Date: Fri, 03 Oct 2014 15:15:54 +0200 From: Erik Trulsson To: "O. Hartmann" Subject: Re: CURRENT: ath0: stuck beacon; resetting (bmiss count 4) References: <20141003145403.704e85be.ohartman@zedat.fu-berlin.de> In-Reply-To: <20141003145403.704e85be.ohartman@zedat.fu-berlin.de> 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.3.9) X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-uu-se:default, uu-se:default, base:default, @@RPTN) X-Spam-Score: -0.10 () [Tag at 15.00] T_RP_MATCHES_RCVD:-0.1 X-p0f-Info: os=Linux 2.6.x, link=Ethernet or modem X-CanIt-Geo: ip=130.238.7.55; country=SE; region=Uppsala; city=Uppsala; latitude=59.8500; longitude=17.6333; http://maps.google.com/maps?q=59.8500,17.6333&z=6 X-CanItPRO-Stream: outbound-uu-se:outbound (inherits from outbound-uu-se:default, uu-se:default, base:default) X-Canit-Stats-ID: 0aMWBfU9b - 60a381333502 - 20141003 X-Antispam-Training-Forget: https://mailfilter.sunet.se/canit/b.php?i=0aMWBfU9b&m=60a381333502&t=20141003&c=f X-Antispam-Training-Nonspam: https://mailfilter.sunet.se/canit/b.php?i=0aMWBfU9b&m=60a381333502&t=20141003&c=n X-Antispam-Training-Spam: https://mailfilter.sunet.se/canit/b.php?i=0aMWBfU9b&m=60a381333502&t=20141003&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.202 X-Mailman-Approved-At: Fri, 03 Oct 2014 13:28:14 +0000 Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 13:24:42 -0000 Quoting "O. Hartmann" : > Since a couple of days I get this weird console-and-log-spamming message: > > ath0: stuck beacon; resetting (bmiss count 4) > > The machine in question is running the most recent CURRENT right now: > > FreeBSD 11.0-CURRENT #2 r272471: Fri Oct 3 13:03:58 CEST 2014 amd64 > > and the box acts as a gateway with WiFi access point via hostapd and > this WiFi hardware: > > [...] > ath0: mem 0xf7e00000-0xf7e0ffff irq 16 at device 0.0 on pci1 > ath0: [HT] enabling HT modes > ath0: [HT] enabling short-GI in 20MHz mode > ath0: [HT] 1 stream STBC receive enabled > ath0: [HT] 1 stream STBC transmit enabled > ath0: [HT] 2 RX streams; 2 TX streams > [...] > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > What is this and how can I get rid of it? It means that you have run into a well-known and long lasting hardware bug in Atheros Wifi chipsets, where they sometimes get stuck and stops sending out beacons. You get that message when the device driver detects that this has happened and resets the chip to get things going again. There is, AFAIK, no way of making sure the problem cannot happen, but you might be able to reduce the frequency of it happening by reducing the amount of interference you receive from other wireless devices. From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 13:33:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8E3275 for ; Fri, 3 Oct 2014 13:33:08 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A1801D81 for ; Fri, 3 Oct 2014 13:33:08 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1Xa2yo-001jv9-L8>; Fri, 03 Oct 2014 15:33:06 +0200 Received: from g225107160.adsl.alicedsl.de ([92.225.107.160] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1Xa2yo-003OaM-HP>; Fri, 03 Oct 2014 15:33:06 +0200 Date: Fri, 3 Oct 2014 15:33:06 +0200 From: "O. Hartmann" To: Erik Trulsson Subject: Re: CURRENT: ath0: stuck beacon; resetting (bmiss count 4) Message-ID: <20141003153306.0e0db45c.ohartman@zedat.fu-berlin.de> In-Reply-To: <20141003151554.19434wd2pn8bwlu2@webmail.uu.se> References: <20141003145403.704e85be.ohartman@zedat.fu-berlin.de> <20141003151554.19434wd2pn8bwlu2@webmail.uu.se> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/zR1ms=sFjvL6I5B9fVQ+nh+"; protocol="application/pgp-signature" X-Originating-IP: 92.225.107.160 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 13:33:09 -0000 --Sig_/zR1ms=sFjvL6I5B9fVQ+nh+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 03 Oct 2014 15:15:54 +0200 Erik Trulsson schrieb: > Quoting "O. Hartmann" : >=20 > > Since a couple of days I get this weird console-and-log-spamming messag= e: > > > > ath0: stuck beacon; resetting (bmiss count 4) > > > > The machine in question is running the most recent CURRENT right now: > > > > FreeBSD 11.0-CURRENT #2 r272471: Fri Oct 3 13:03:58 CEST 2014 amd64 > > > > and the box acts as a gateway with WiFi access point via hostapd and =20 > > this WiFi hardware: > > > > [...] > > ath0: mem 0xf7e00000-0xf7e0ffff irq 16 at device 0.0 on = pci1 > > ath0: [HT] enabling HT modes > > ath0: [HT] enabling short-GI in 20MHz mode > > ath0: [HT] 1 stream STBC receive enabled > > ath0: [HT] 1 stream STBC transmit enabled > > ath0: [HT] 2 RX streams; 2 TX streams > > [...] > > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 > > > > What is this and how can I get rid of it? >=20 > It means that you have run into a well-known and long lasting hardware =20 > bug in Atheros Wifi chipsets, where they sometimes get stuck and stops =20 > sending out beacons. > You get that message when the device driver detects that this has =20 > happened and resets the chip to get things going again. >=20 > There is, AFAIK, no way of making sure the problem cannot happen, but =20 > you might be able to reduce the frequency of it happening by reducing =20 > the amount of interference you receive from other wireless devices. Ah, I understand, so nothing to worry about. The WiFi NIC is a cheap TP Lin= k facility. Hopefully, FreeBSD will have support for Intel's Dual Band 7260-chipset thi= s decade, so the problem will be gone anyway (except Intel put also nice hardware bugs i= nto their silica ...). oh --Sig_/zR1ms=sFjvL6I5B9fVQ+nh+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJULqWSAAoJEOgBcD7A/5N8gm8IALFT3XCAvVnIX4/npOFuvZY4 LY1aHOxyAtQtGQEckmqheOUyD8X1U2nirFq3HSOEx0oqw8nXjkocogP8sWIqVB8j DxVe/B6GRO67TjLOPeZbVAbO583oMzaThBbJleAMRudHqF9zCDf+HZ9YRxIeDhEd chfCoNM1KRDDnGiOp1+xJxcawPp75I+ymGMqTNUk+qmv4bzFwiD3gRjZ9/n2gHMG g9hmpl4Z7PLPrWDIjIKYb/M0lXON+ON2Vblk8/NTTr60LvE+dNhSl3mB8ckYpPgE fAqvyUxg9wE9ddTSRrYLcjar0m5eFwP3lxm1zHHOgBeg0i+XpDZnM1I/jkn7xPI= =CaF1 -----END PGP SIGNATURE----- --Sig_/zR1ms=sFjvL6I5B9fVQ+nh+-- From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 13:41:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 865BD334; Fri, 3 Oct 2014 13:41:04 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 407D8DDE; Fri, 3 Oct 2014 13:41:04 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Xa36O-000Ph9-AP; Fri, 03 Oct 2014 17:40:56 +0400 Date: Fri, 3 Oct 2014 17:40:56 +0400 From: Slawa Olhovchenkov To: "O. Hartmann" Subject: Re: [CURRENT] hostapd: WPA w/ EAP-TTLS or EAP-PEAP or EAP-TLS ? Message-ID: <20141003134056.GA96750@zxy.spb.ru> References: <20141003151453.620a1f2b.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141003151453.620a1f2b.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: FreeBSD CURRENT , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 13:41:04 -0000 On Fri, Oct 03, 2014 at 03:14:53PM +0200, O. Hartmann wrote: > > Where is the support on WPA with EAP-TTLS or EAP-PEAP or EAP-TLS in hostapd? > > Trying to circumvent FreeBSD's very poor documentation on the options of hostapd, I found > lots of howtos for Linuxes of different flavours utilizing obviously the same hostapd > basis. But whenever I try to configure one of the above mentioned auth methods for a > gateway I try to configure (CURRENT, 10.1-PRE), I get an error. > > What is up here? You need to recompile source. And patching some Makefiles, AFAIR. From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 14:04:17 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03B36AB4; Fri, 3 Oct 2014 14:04:17 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CDE5E116; Fri, 3 Oct 2014 14:04:16 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 04BC4B984; Fri, 3 Oct 2014 10:04:15 -0400 (EDT) From: John Baldwin To: Gleb Smirnoff Subject: Re: [PATCH] Fix OACTIVE for an(4) Date: Fri, 03 Oct 2014 08:58:25 -0400 Message-ID: <16070615.NdPaubu6kG@ralph.baldwin.cx> User-Agent: KMail/4.12.5 (FreeBSD/10.1-BETA2; KDE/4.12.5; amd64; ; ) In-Reply-To: <20141003081328.GZ73266@FreeBSD.org> References: <2113392.UOaBFTpimf@ralph.baldwin.cx> <201410021116.27583.jhb@freebsd.org> <20141003081328.GZ73266@FreeBSD.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 03 Oct 2014 10:04:15 -0400 (EDT) Cc: Adrian Chadd , freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 14:04:17 -0000 On Friday, October 03, 2014 12:13:28 PM Gleb Smirnoff wrote: > On Thu, Oct 02, 2014 at 11:16:27AM -0400, John Baldwin wrote: > J> > I haven't looked at the rest of the driver; is everything else around > J> > OACTIVE locked correctly and consistently? > J> > J> As well as OACTIVE is for any other driver. > > Let me jump into this topic and discuss the if_drv_flags :) > > It seems to me that this in general was a wrong concept, both > IFF_DRV_OACTIVE and IFF_DRV_RUNNING. The internal state of > the driver can be known only to the driver itself and should > be stored in the softc, covered with internal lock. > > There is simply no way to racelessly tell the state from the > outside, without obtaining driver lock. > > In my ifnet plans I am considering to remove if_drv_flags. > Can anyone convince me that this is a wrong idea and they > should be kept? They used to be in if_flags. Robert moved them to if_drv_flags precisely so that drivers could control their synchronization instead of doing a crazy locking dance with the ifnet layer. They are still exported to userland as IFF_RUNNING and IFF_OACTIVE in if_flags, and they may still be somewhat useful for reporting that state to userland (and races in reading if_drv_flags for that reporting are harmless). That said, I think long term if we make the stack aware of multiple input queues we will certainly use something that does not have the same raciness as OACTIVE. Note, btw, you could fix OACTIVE in various drivers by simply grabbing the IF_LOCK on ifp->if_snd while setting or clearing OACTIVE to close the current OACTIVE race (you don't need it for all writes to if_drv_flags, you just want if_handoff() to read the current value of OACTIVE, so only locking writes to OACTIVE would be sufficient). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 15:14:47 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31A35770; Fri, 3 Oct 2014 15:14:47 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0D1D3B06; Fri, 3 Oct 2014 15:14:45 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA23920; Fri, 03 Oct 2014 18:14:37 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Xa4Z2-0003kA-LG; Fri, 03 Oct 2014 18:14:36 +0300 Message-ID: <542EBD1F.2060604@FreeBSD.org> Date: Fri, 03 Oct 2014 18:13:35 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: FreeBSD Current Subject: Re: vt_suspend / vt_resume References: <542A43E1.5010401@FreeBSD.org> In-Reply-To: <542A43E1.5010401@FreeBSD.org> Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:14:47 -0000 On 30/09/2014 08:47, Andriy Gapon wrote: > > I think that currently vt_suspend / vt_resume are called at quite unsuitable > times. For example, vt_suspend performs a vt switch which requires cooperation > from an X server, but that could be problematic given that some devices may > already be suspended. > I believe that it is better to do what sc(4) does and use power_suspend / > power_resume event handlers instead of device_suspend / device_resume methods. > power_suspend event is posted when a kernel has not entered any special state yet. > > What do you think? > So, I am now using the following patch and suspend/resume works 100% reliable for me, whereas previously there was a quite significant chance that the video subsystem would be in a very confused state after resuming. For example there could be an endless stream of error message and the screen would be frozen: drmn0: error: couldn't schedule ib error: [drm:pid1492:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! Or there could be an endless GPU reset loop in the radeon driver: drmn0: error: GPU lockup CP stall for more than 10000msec drmn0: warning: GPU lockup (waiting for 0x0000000000269544 last fence id 0x0000000000269523) error: [drm:pid1492:r600_ib_test] *ERROR* radeon: fence wait failed (-11). error: [drm:pid1492:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on GFX ring (-11). drmn0: error: ib ring test failed (-11). drmn0: info: GPU softreset: 0x00000003 The patch (I am not sure if fbd_attach is the right place to register the event handlers): diff --git a/sys/dev/fb/fbd.c b/sys/dev/fb/fbd.c index ff2488d..923292a 100644 --- a/sys/dev/fb/fbd.c +++ b/sys/dev/fb/fbd.c @@ -316,6 +316,11 @@ fbd_attach(device_t dev) return (ENXIO); err = fbd_register(sc->sc_info); + EVENTHANDLER_REGISTER(power_suspend, vt_fb_suspend, NULL, + EVENTHANDLER_PRI_ANY); + EVENTHANDLER_REGISTER(power_resume, vt_fb_resume, NULL, + EVENTHANDLER_PRI_ANY); + return (err); } @@ -332,22 +337,6 @@ fbd_detach(device_t dev) return (err); } -static int -fbd_suspend(device_t dev) -{ - - vt_fb_suspend(); - return (bus_generic_suspend(dev)); -} - -static int -fbd_resume(device_t dev) -{ - - vt_fb_resume(); - return (bus_generic_resume(dev)); -} - static device_method_t fbd_methods[] = { /* Device interface */ DEVMETHOD(device_probe, fbd_probe), @@ -355,8 +344,6 @@ static device_method_t fbd_methods[] = { DEVMETHOD(device_detach, fbd_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), - DEVMETHOD(device_suspend, fbd_suspend), - DEVMETHOD(device_resume, fbd_resume), { 0, 0 } }; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 15:21:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5EADAB2 for ; Fri, 3 Oct 2014 15:21:38 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B44DC0F for ; Fri, 3 Oct 2014 15:21:38 +0000 (UTC) Received: from zeppelin.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s93FLMuu012235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 3 Oct 2014 08:21:22 -0700 Message-ID: <542EBEF1.1080200@freebsd.org> Date: Fri, 03 Oct 2014 08:21:21 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: vt_suspend / vt_resume References: <542A43E1.5010401@FreeBSD.org> <542EBD1F.2060604@FreeBSD.org> In-Reply-To: <542EBD1F.2060604@FreeBSD.org> X-Sonic-CAuth: UmFuZG9tSVaqKz7bfuWdfxDHUSubOB6ekh39l8noq2g4EgEu8AUBPKfaEae0zYtpgfmNBr+RHHrxQBMLcYpD1000qpp+mw9RW2u6VCDh/L0= X-Sonic-ID: C;vEuB7hBL5BG714R6lZB5Vg== M;SDj+7hBL5BG714R6lZB5Vg== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:21:38 -0000 On 10/03/14 08:13, Andriy Gapon wrote: > On 30/09/2014 08:47, Andriy Gapon wrote: >> I think that currently vt_suspend / vt_resume are called at quite unsuitable >> times. For example, vt_suspend performs a vt switch which requires cooperation >> from an X server, but that could be problematic given that some devices may >> already be suspended. >> I believe that it is better to do what sc(4) does and use power_suspend / >> power_resume event handlers instead of device_suspend / device_resume methods. >> power_suspend event is posted when a kernel has not entered any special state yet. >> >> What do you think? >> > > So, I am now using the following patch and suspend/resume works 100% reliable > for me, whereas previously there was a quite significant chance that the video > subsystem would be in a very confused state after resuming. > > For example there could be an endless stream of error message and the screen > would be frozen: > drmn0: error: couldn't schedule ib > error: [drm:pid1492:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB ! > > Or there could be an endless GPU reset loop in the radeon driver: > drmn0: error: GPU lockup CP stall for more than 10000msec > drmn0: warning: GPU lockup (waiting for 0x0000000000269544 last fence id > 0x0000000000269523) > error: [drm:pid1492:r600_ib_test] *ERROR* radeon: fence wait failed (-11). > error: [drm:pid1492:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on > GFX ring (-11). > drmn0: error: ib ring test failed (-11). > drmn0: info: GPU softreset: 0x00000003 > > The patch (I am not sure if fbd_attach is the right place to register the event > handlers): It's not, I don't think, since fbd_attach() isn't called for all vt backends (e.g. the VGA and EFI backends don't call it). vt_fb_suspend() also only calls vt_suspend(), so it's probably best to put this in the core vt code. -Nathan > diff --git a/sys/dev/fb/fbd.c b/sys/dev/fb/fbd.c > index ff2488d..923292a 100644 > --- a/sys/dev/fb/fbd.c > +++ b/sys/dev/fb/fbd.c > @@ -316,6 +316,11 @@ fbd_attach(device_t dev) > return (ENXIO); > err = fbd_register(sc->sc_info); > > + EVENTHANDLER_REGISTER(power_suspend, vt_fb_suspend, NULL, > + EVENTHANDLER_PRI_ANY); > + EVENTHANDLER_REGISTER(power_resume, vt_fb_resume, NULL, > + EVENTHANDLER_PRI_ANY); > + > return (err); > } > > @@ -332,22 +337,6 @@ fbd_detach(device_t dev) > return (err); > } > > -static int > -fbd_suspend(device_t dev) > -{ > - > - vt_fb_suspend(); > - return (bus_generic_suspend(dev)); > -} > - > -static int > -fbd_resume(device_t dev) > -{ > - > - vt_fb_resume(); > - return (bus_generic_resume(dev)); > -} > - > static device_method_t fbd_methods[] = { > /* Device interface */ > DEVMETHOD(device_probe, fbd_probe), > @@ -355,8 +344,6 @@ static device_method_t fbd_methods[] = { > DEVMETHOD(device_detach, fbd_detach), > > DEVMETHOD(device_shutdown, bus_generic_shutdown), > - DEVMETHOD(device_suspend, fbd_suspend), > - DEVMETHOD(device_resume, fbd_resume), > > { 0, 0 } > }; > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 17:03:04 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97749D58; Fri, 3 Oct 2014 17:03:04 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DC25935; Fri, 3 Oct 2014 17:03:03 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s93H2xSu092176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2014 20:02:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s93H2xSu092176 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s93H2xcX092175; Fri, 3 Oct 2014 20:02:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 3 Oct 2014 20:02:59 +0300 From: Konstantin Belousov To: x11@freebsd.org Subject: i915 driver update testing Message-ID: <20141003170258.GG26076@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 17:03:04 -0000 Please find at the https://kib.kiev.ua/kib/drm/i915.1.patch a patch which provides some updates to the i915 driver. At large, this is import of the batch of Linux commits, and as such, it is interesting mostly as attempt to restart the race to get us more up to date Linux code imported. It might provide some bug fixes, most likely for IvyBridge. Interesting from the development PoV is the update of the GEM i/o ioctl code path to mimic Linux code structure. I am asking _only_ for reports of regressions with the patch applied, comparing with the code which is currently in HEAD. I will not debug any existing bugs, my goal right now is to commit this update, which is needed for further work. I.e., only when you get an issue with the patch applied, but cannot reproduce the problem without the patch, please prepare a bug report. FYI, the driver will attach to haswell gfx, but I am not interested in reports about this (see above paragraph). On my test box, which is Core i7 4770S, the mode-setting and front-buffer rendering works, but Mesa immediately cause renderer to bug out. Work was sponsored by The FreeBSD Foundation, both by time and hardware, and Intel provided access to the documentation. From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 17:55:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76BE9559 for ; Fri, 3 Oct 2014 17:55:23 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10220ED0 for ; Fri, 3 Oct 2014 17:55:22 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hi2so2121909wib.3 for ; Fri, 03 Oct 2014 10:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=T2YzhSYq4bLqkUf4gtFxtT7VO9x7Ite5TIUEr1oz10g=; b=l5Bv388rVR+Ik+lwJ0umR9Zw7dGhb9amaI5TjZjhT38NtM3/JHJo0ZfdEbC3EKI+Zd na5igmo3glmu/5s/HiSjbj+GEPScvqX0T5GZxs8j5EPAIBcfdvoKB2gTPjfbpTWHixZt +NdicAxpU3tspbhaqV0dCozkd8xqPQzETO/RjekLVErTe+vMIcK0tDfp1mpM/T9AOWrM MoH0nEb0u4o+srw0369WP/GyBVI2xPXeCW81EvxVJD92RRVIxlKX1TnB4v7jzz9tUZYQ LL8PMol1R/Oz2qfgxP9OeLrgN1aPLnUC+QiI6TbRT7c/VvIhhDVPlNTBtvvYxMqCtr1c 5oNQ== MIME-Version: 1.0 X-Received: by 10.180.74.203 with SMTP id w11mr179600wiv.26.1412358921306; Fri, 03 Oct 2014 10:55:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 3 Oct 2014 10:55:21 -0700 (PDT) In-Reply-To: <20141003153306.0e0db45c.ohartman@zedat.fu-berlin.de> References: <20141003145403.704e85be.ohartman@zedat.fu-berlin.de> <20141003151554.19434wd2pn8bwlu2@webmail.uu.se> <20141003153306.0e0db45c.ohartman@zedat.fu-berlin.de> Date: Fri, 3 Oct 2014 10:55:21 -0700 X-Google-Sender-Auth: M5MAVzEmS0Szm9JYsVd_ZzYK7R8 Message-ID: Subject: Re: CURRENT: ath0: stuck beacon; resetting (bmiss count 4) From: Adrian Chadd To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD CURRENT , Erik Trulsson X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 17:55:23 -0000 I think you're going to be .. unhappy with what Intel's firmware is like as an AP. I still have to chase down why the AR9287 stalls and do a full chip reset when it goes RX deaf. I'm just chasing down other things at the moment. -a On 3 October 2014 06:33, O. Hartmann wrote: > Am Fri, 03 Oct 2014 15:15:54 +0200 > Erik Trulsson schrieb: > >> Quoting "O. Hartmann" : >> >> > Since a couple of days I get this weird console-and-log-spamming message: >> > >> > ath0: stuck beacon; resetting (bmiss count 4) >> > >> > The machine in question is running the most recent CURRENT right now: >> > >> > FreeBSD 11.0-CURRENT #2 r272471: Fri Oct 3 13:03:58 CEST 2014 amd64 >> > >> > and the box acts as a gateway with WiFi access point via hostapd and >> > this WiFi hardware: >> > >> > [...] >> > ath0: mem 0xf7e00000-0xf7e0ffff irq 16 at device 0.0 on pci1 >> > ath0: [HT] enabling HT modes >> > ath0: [HT] enabling short-GI in 20MHz mode >> > ath0: [HT] 1 stream STBC receive enabled >> > ath0: [HT] 1 stream STBC transmit enabled >> > ath0: [HT] 2 RX streams; 2 TX streams >> > [...] >> > ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 >> > >> > What is this and how can I get rid of it? >> >> It means that you have run into a well-known and long lasting hardware >> bug in Atheros Wifi chipsets, where they sometimes get stuck and stops >> sending out beacons. >> You get that message when the device driver detects that this has >> happened and resets the chip to get things going again. >> >> There is, AFAIK, no way of making sure the problem cannot happen, but >> you might be able to reduce the frequency of it happening by reducing >> the amount of interference you receive from other wireless devices. > > Ah, I understand, so nothing to worry about. The WiFi NIC is a cheap TP Link facility. > Hopefully, FreeBSD will have support for Intel's Dual Band 7260-chipset this decade, so > the problem will be gone anyway (except Intel put also nice hardware bugs into their > silica ...). > > > oh From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 19:23:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D8FC7D5; Fri, 3 Oct 2014 19:23:00 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 049F2ABC; Fri, 3 Oct 2014 19:22:59 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id fb4so3765485wid.0 for ; Fri, 03 Oct 2014 12:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OhrWoFmSj0KWtQ8g/nWsEPSXW42GgPb8GcLmTETxsvI=; b=gknHwUfIqFyDGRdRsLKFvjXDr/XzTJ4JoT72TCJ30C5Mt8/XDUsOhz8bf0CWocCo4C yU6gfceWY1p4hlPH2hl7kdjn3XfMhBLQnb2iPv3nT+TJJeeJqHZD5+9JefsFxC9+rx/8 Y6SMrIQXckVD33X0LFvRXcjy62eQmo9K1MzBetNZlGLIlG/Gzc5/tlBe5L54SqOv3TLS nQV1upcG3yzVfvjT243pQ6HIDprRcFYDsmrROMuCcCAh1kIIh75Uog+paVbsC1kmM+rD c4ylkw1yyS/rQFdpZ265FRa6OvcsVup/0cM51KE4Oe/TeB3wt7rQjElUxdNujVm/xzVF +qMw== MIME-Version: 1.0 X-Received: by 10.180.80.98 with SMTP id q2mr697523wix.20.1412364178239; Fri, 03 Oct 2014 12:22:58 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Fri, 3 Oct 2014 12:22:58 -0700 (PDT) In-Reply-To: <20141003151453.620a1f2b.ohartman@zedat.fu-berlin.de> References: <20141003151453.620a1f2b.ohartman@zedat.fu-berlin.de> Date: Fri, 3 Oct 2014 12:22:58 -0700 X-Google-Sender-Auth: uQLE3fjg-HJQRI2wKJdkClvJE4g Message-ID: Subject: Re: [CURRENT] hostapd: WPA w/ EAP-TTLS or EAP-PEAP or EAP-TLS ? From: Adrian Chadd To: "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD CURRENT , FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:23:00 -0000 Documentation updates to hostapd / wifi for the handbook and manpages are very, very welcome. -a On 3 October 2014 06:14, O. Hartmann wrote: > > Where is the support on WPA with EAP-TTLS or EAP-PEAP or EAP-TLS in hostapd? > > Trying to circumvent FreeBSD's very poor documentation on the options of hostapd, I found > lots of howtos for Linuxes of different flavours utilizing obviously the same hostapd > basis. But whenever I try to configure one of the above mentioned auth methods for a > gateway I try to configure (CURRENT, 10.1-PRE), I get an error. > > What is up here? > > Regards, > Oliver From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 19:29:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 100D4B89 for ; Fri, 3 Oct 2014 19:29:53 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C35DB2C for ; Fri, 3 Oct 2014 19:29:52 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id gi9so1651694lab.33 for ; Fri, 03 Oct 2014 12:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=A75AuIS7E8JiAuThIfD3o7SK2UX6tXYr/2vSMR58SeU=; b=xQ/67EMnDGiWZzk31I66B7ESk8gyPHKxhE8LDBysT7tJh0xJjwyBwy2N1o/lln4GES u+Adwj+h0PdwAhbQlWqVkXHraJRlkuT/xO/EWP9amGHTKbdGUlFH5SCVdDuoOHua4148 Yz3tK4KjS/TW6OqFgsxwnhV8vfIUSNcRfkMy4+jwK+AORRjMmSFJPmccG43U9mYvrT6G MXOGd+P5BltJmjJ2xADliKMBHkWXQsmEAbSAHWXxqqo+8FbmQLRxXdqxYsK42r9vqdkL 2X5cKQBHd8LHpauvOoNJbwmJhEe58gxwayIG6CcG5SaDRc1QPwWo5eV0F3YTJCC28fse 9KRQ== X-Received: by 10.152.197.35 with SMTP id ir3mr8321751lac.82.1412364590494; Fri, 03 Oct 2014 12:29:50 -0700 (PDT) Received: from dw.org.pl (aekq203.neoplus.adsl.tpnet.pl. [79.191.16.203]) by mx.google.com with ESMTPSA id rl6sm2987033lac.17.2014.10.03.12.29.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Oct 2014 12:29:49 -0700 (PDT) From: Dariusz Wierzbicki X-Google-Original-From: Dariusz Wierzbicki Date: Fri, 3 Oct 2014 21:29:46 +0200 To: Yonghyeon PYUN Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support Message-ID: <20141003212946.1499d68f@dw.org.pl> In-Reply-To: <20141002050730.GA964@michelle.fasterthan.com> References: <20140930015741.GA2451@michelle.fasterthan.com> <20141001013637.GD2632@michelle.fasterthan.com> <20141002050730.GA964@michelle.fasterthan.com> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:29:53 -0000 Dnia 2014-10-02, o godz. 14:07:30 Yonghyeon PYUN napisa=C5=82(a): > On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote: > > On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote: > > > Hi, > > > I've added support for QAC AR816x/AR817x ethernet controllers. It > > > passed my limited testing and I need more testers. You can find > > > patches from the following URLs. > > >=20 > > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff > > > and > > > http://people.freebsd.org/~yongari/alc/alc.diff.20140930 > > >=20 > > > pci.qurik.diff is to workaround silicon bug of AR816x. Without it > > > MSI/MSIX interrupt wouldn't work. If you just want to use > > > legacy INTx interrupt you don't have to apply it but you have to > > > tell alc(4) not to use MSI/MSIX interrupt with tunables( > > > hw.alc.msi.disable and hw.alc.msix_disable). > > >=20 > > > alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172 > > > and E2200 controllers. It supports all hardware features except > > > RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x > > > controllers please test and report how the diff works for you. > > > Thanks. > >=20 > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff > > http://people.freebsd.org/~yongari/alc/alc.diff.20141001 > >=20 > > Patch updated to address link establishment issue. >=20 > http://people.freebsd.org/~yongari/alc/alc.diff.20141002 > Patch updated again to correct wrong lock assertion. Hi ! Thanks for your work ! Are your patches only for current ? I tried on 10 stable. My system: dw@dw:~ % uname -a FreeBSD dw 10.1-RC1 FreeBSD 10.1-RC1 #1 r272477M: Fri Oct 3 20:48:05 CEST 2014 dw@dw:/usr/obj/usr/src/sys/DW amd64 I applied your patches (pci.quirk.diff & alc.diff.20141002). There was a minor problem with alc.diff.20141002 - hunk 1 failed: @@ -111,17 +111,31 @@ "Atheros AR8152 v1.1 PCIe Fast Ethernet" }, { VENDORID_ATHEROS, DEVICEID_ATHEROS_AR8152_B2, 6 * 1024, "Atheros AR8152 v2.0 PCIe Fast Ethernet" }, + { VENDORID_ATHEROS, DEVICEID_ATHEROS_AR8161, 9 * 1024, + "Atheros AR8161 PCIe Gigabit Ethernet" }, + { VENDORID_ATHEROS, DEVICEID_ATHEROS_AR8162, 9 * 1024, + "Atheros AR8161 PCIe Fast Ethernet" }, + { VENDORID_ATHEROS, DEVICEID_ATHEROS_AR8171, 9 * 1024, + "Atheros AR8161 PCIe Gigabit Ethernet" }, + { VENDORID_ATHEROS, DEVICEID_ATHEROS_AR8172, 9 * 1024, + "Atheros AR8161 PCIe Fast Ethernet" }, + { VENDORID_ATHEROS, DEVICEID_ATHEROS_E2200, 9 * 1024, + "Atheros AR8161 PCIe Killer E2200 Gigabit Ethernet" }, { 0, 0, 0, NULL} }; =20 -static void alc_aspm(struct alc_softc *, int); +static void alc_aspm(struct alc_softc *, int, int); +static void alc_aspm_813x(struct alc_softc *, int); +static void alc_aspm_816x(struct alc_softc *, int); static int alc_attach(device_t); static int alc_check_boundary(struct alc_softc *); +static void alc_config_msi(struct alc_softc *); static int alc_detach(device_t); static void alc_disable_l0s_l1(struct alc_softc *); static int alc_dma_alloc(struct alc_softc *); static void alc_dma_free(struct alc_softc *); static void alc_dmamap_cb(void *, bus_dma_segment_t *, int, int); +static void alc_dsp_fixup(struct alc_softc *, int); static int alc_encap(struct alc_softc *, struct mbuf **); static struct alc_ident * alc_find_ident(device_t); I applied that part manually. Compiled and rebooted system. dmesg | grep alc : alc0: could not disable Rx/Tx MAC(0x4000cb20)! alc0: reset timeout(0x4000cb20)! alc0: could not disable Rx/Tx MAC(0x4000cb20)! alc0: link state changed to UP alc0: could not disable Rx/Tx MAC(0x4000cb20)! alc0: port 0xd000-0xd07f mem 0xf7200000-0xf723ffff irq 18 at device 0.0 on pci3 alc0: reset timeout(0x4000cd00)! alc0: 11776 Tx FIFO, 12032 Rx FIFO miibus0: on alc0 alc0: Ethernet address: 74:d4:35:91:32:04 alc0: could not disable Rx/Tx MAC(0x4000cd00)! alc0: reset timeout(0x4000cd00)! alc0: port 0xd000-0xd07f mem 0xf7200000-0xf723ffff irq 18 at device 0.0 on pci3 alc0: reset timeout(0x4000ca00)! alc0: 11776 Tx FIFO, 12032 Rx FIFO miibus0: on alc0 alc0: Ethernet address: 74:d4:35:91:32:04 alc0: port 0xd000-0xd07f mem 0xf7200000-0xf723ffff irq 18 at device 0.0 on pci3 alc0: PCI device revision : 0x0010 alc0: Chip id/revision : 0xc002 alc0: AR816x revision : 0x2 alc0: 11776 Tx FIFO, 12032 Rx FIFO alc0: Read request size : 512 bytes. alc0: TLP payload size : 128 bytes. alc0: MSIX count : 16 alc0: MSI count : 16 alc0: attempting to allocate 1 MSI-X vectors (16 supported) alc0: using IRQ 268 for MSI-X alc0: Using 1 MSIX message(s). miibus0: on alc0 alc0: bpf attached alc0: Ethernet address: 74:d4:35:91:32:04 alc0: link state changed to UP pciconf -vlc : alc0@pci0:3:0:0: class=3D0x020000 card=3D0xe0001458 chip=3D0x10911969 rev=3D0x10 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR8161 Gigabit Ethernet' class =3D network subclass =3D ethernet cap 01[40] =3D powerspec 3 supports D0 D3 current D0 cap 10[58] =3D PCI-Express 1 endpoint max data 128(4096) link x1(x1) speed 2.5(2.5) ASPM disabled(L0s/L1) cap 05[c0] =3D MSI supports 16 messages, 64 bit, vector masks=20 cap 11[d8] =3D MSI-X supports 16 messages, enabled Table in map 0x10[0x2000], PBA in map 0x10[0x3000] ecap 0001[100] =3D AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[180] =3D Serial 1 ff91320474d435ff ifconfig : alc0: flags=3D8843 metric 0 mtu 1500 options=3Dc319a ether 74:d4:35:91:32:04 inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active If you need other data or more testing, let me know. Kind regards, Darek From owner-freebsd-current@FreeBSD.ORG Fri Oct 3 21:58:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DAEF712C; Fri, 3 Oct 2014 21:58:37 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E7F4C96; Fri, 3 Oct 2014 21:58:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s93LwWNb086896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Oct 2014 00:58:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s93LwWNb086896 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s93LwU14086895; Sat, 4 Oct 2014 00:58:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Oct 2014 00:58:30 +0300 From: Konstantin Belousov To: Kohji Okuno Subject: Re: About pmap_mapdev() & pmap_unmapdev() Message-ID: <20141003215830.GK26076@kib.kiev.ua> References: <20141003.172533.863334695746935674.okuno.kohji@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141003.172533.863334695746935674.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: stable@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 21:58:38 -0000 On Fri, Oct 03, 2014 at 05:25:33PM +0900, Kohji Okuno wrote: > Hi, > > At least in i386 && 9-stable, when we call pmap_mapdev() and > pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased > incorrectly. > > pmap_mapdev_attr()->pmap_kenter_attr(): > In this path, kernel_pmap.pm_stats.resident_count is not increlmented. > > pmap_unmapdev()->kmem_free(kernel_map)->vm_map_remove()->pmap_remove(): > But, in this path, kernel_pmap.pm_stats.resident_count is decreased in > pmap_remove_pte(). > > While I called pmap_mapdev() and pmap_unmapdev() repeatedly and > kernel_pmap.pm_stats.resident_count became `0', since pmap_remove() > returned without removing ptes, I encountered various kernel panics. I think you are right. The problem seems to be fixed in HEAD and 10, since mapdev was switched to use kva_alloc/kva_free. I added stable@ to Cc:. > > And, when I enabled INVARIANTS, I looked the following panic message. > panic: vm_page_free_toq: freeing mapped page 0xXXXXXXXX. Do you mean that this panic is related to missed pmap_remove() ? I doubt it, since pmap_mapdev() does not establish managed mappings. > > I think, I should change the following. > What do you think about this? > > > diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c > index 2adc6f8..a0998e8 100644 > --- a/sys/i386/i386/pmap.c > +++ b/sys/i386/i386/pmap.c > @@ -5061,6 +5061,7 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode) > { > vm_offset_t va, offset; > vm_size_t tmpsize; > + int kmem_allocated = 0; > > offset = pa & PAGE_MASK; > size = roundup(offset + size, PAGE_SIZE); > @@ -5068,13 +5069,18 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode) > > if (pa < KERNLOAD && pa + size <= KERNLOAD) > va = KERNBASE + pa; > - else > + else { > va = kmem_alloc_nofault(kernel_map, size); > + kmem_allocated = 1; You could just do PMAP_LOCK(kernel_pmap); kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size); PMAP_UNLOCK(kernel_pmap); there. And, the same fix is needed for amd64. > + } > if (!va) > panic("pmap_mapdev: Couldn't alloc kernel virtual memory"); > > - for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) > + for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) { > pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode); > + if (kmem_allocated) > + kernel_pmap.pm_stats.resident_count++; > + } > pmap_invalidate_range(kernel_pmap, va, va + tmpsize); > pmap_invalidate_cache_range(va, va + size); > return ((void *)(va + offset)); > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 06:47:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95C45C0A; Sat, 4 Oct 2014 06:47:41 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DF51992; Sat, 4 Oct 2014 06:47:40 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XaJ7y-0001qs-Ng>; Sat, 04 Oct 2014 08:47:38 +0200 Received: from e179164176.adsl.alicedsl.de ([85.179.164.176] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XaJ7y-000rZV-IN>; Sat, 04 Oct 2014 08:47:38 +0200 Date: Sat, 4 Oct 2014 08:47:37 +0200 From: "O. Hartmann" To: Harald Schmalzbauer Subject: Re: CURRENT: EFI boot failure Message-ID: <20141004084737.64b35fd8.ohartman@zedat.fu-berlin.de> In-Reply-To: <542188DC.8000307@omnilan.de> References: <20140916020541.03c18d04.ohartman@zedat.fu-berlin.de> <54178607.1060305@freebsd.org> <541786BE.6010105@freebsd.org> <20140916075121.29989a53.ohartman@zedat.fu-berlin.de> <5417E20D.8070607@freebsd.org> <20140916230348.189e80cd.ohartman@zedat.fu-berlin.de> <5418B8C3.7040406@FreeBSD.org> <20140919152207.0473e213.ohartman@zedat.fu-berlin.de> <542183A6.7060802@omnilan.de> <542188DC.8000307@omnilan.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Wu7x9jUNN+v16F1YD7Mii+Y"; protocol="application/pgp-signature" X-Originating-IP: 85.179.164.176 X-ZEDAT-Hint: A Cc: Allan Jude , FreeBSD Current , Ed Maste , Nathan Whitehorn , Andriy Gapon X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 06:47:41 -0000 --Sig_/Wu7x9jUNN+v16F1YD7Mii+Y Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Am Tue, 23 Sep 2014 16:51:08 +0200 Harald Schmalzbauer schrieb: > Bez=FCglich Harald Schmalzbauer's Nachricht vom 23.09.2014 16:28 > (localtime): > > Bez=FCglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime): > >> =85 > >> The problem I reported about in the first place is triggered by a faul= ty loader.efi > >> that arises, when optimisation level is -O3. -O2 works fine. > > I can confirm that this problem also shows up when using > > 'CPUTYPE?=3Dcore-avx2' > > Setting CPUTYPE to core-avx-i doesnt ehibit the problem. > > > > I could narrow down the cause to libefi.a (sys/boot/efi). > > But I don't understand the things going on there, so no clue how to fix > > besides maybe > > > > --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.000000000 +0200 > > +++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.000000000 +0200 > > @@ -2,6 +2,10 @@ > > > > BINDIR?=3D /boot > > > > +.ifdef CPUTYPE > > +.undef CPUTYPE > > +.endif >=20 > Sorry, forget the suggestion, it doesn't work since it leads to CFLAG > -march=3D"" and the same problem occurs. > For my case this works: > --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.000000000 +02= 00 > +++ sys/boot/efi/Makefile.inc 2014-09-23 16:46:30.000000000 +0200 > @@ -2,6 +2,10 @@ > =20 > BINDIR?=3D /boot > =20 > +.if ${CPUTYPE} =3D=3D "core-avx2" > +CPUTYPE=3D core-avx-i > +.endif > + > .if ${MACHINE_CPUARCH} =3D=3D "i386" > CFLAGS+=3D -march=3Di386 > .endif >=20 > JFI >=20 > -Harry >=20 Has this problem anyhow seriously been addressed? I run into this very ofte= n on several platforms with HAswell-based CPUs (other systems with IvyBridge or SandyBri= dge are still to be migrated to UEFI boot, so I do not have any older architectures at ha= nd to proof whether this issue is still present or not on Non-AVX2 systems. If there is no progress so far, would it be well-advised to open a PR? Regards, Oliver=20 --Sig_/Wu7x9jUNN+v16F1YD7Mii+Y Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUL5gKAAoJEOgBcD7A/5N8CuUH/0qJe5V9ogD2fLpkFaY85KAr 9nZbec4LMvnL5nmKLxaOL+PnGyp6YJ/E5eW4yUsfCD9720TDsxmEdRf4ylVSCcSy 2trr3zlSX8tRhXX1BGGpzecMauvVXKrmmZ+erdk+cRNnYsc5ntZesEBFLGBHBgR0 5dTIw72PaNuqwoG8z/C9Q/LA7OWt79K9USiDgV/qcuEXusKDJO4Ob8+G1jvzG5Ff utcLgZ+x1T9XQefWw0fiobouQ00zjxwvHfLN2DB/RcTLA7GUUc2g4f1CdBzyn9K3 F/nTzWmk1DBxyUT+gpUh4+ThOtT0DRDbSaFWlgapVsz28TyvRjSkCZe9vOmfb5U= =Qtrv -----END PGP SIGNATURE----- --Sig_/Wu7x9jUNN+v16F1YD7Mii+Y-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 08:00:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5505C471; Sat, 4 Oct 2014 08:00:40 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 0654FF88; Sat, 4 Oct 2014 08:00:38 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id s9480adI029482; Sat, 4 Oct 2014 17:00:36 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili17) with ESMTP id s9480aA28376; Sat, 4 Oct 2014 17:00:36 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi17) id s9480aRU013147; Sat, 4 Oct 2014 17:00:36 +0900 Received: from localhost by lomi17.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s9480aBG013127; Sat, 4 Oct 2014 17:00:36 +0900 Date: Sat, 04 Oct 2014 17:00:36 +0900 (JST) Message-Id: <20141004.170036.336251378907610162.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com Subject: Re: About pmap_mapdev() & pmap_unmapdev() From: Kohji Okuno In-Reply-To: <20141003215830.GK26076@kib.kiev.ua> References: <20141003.172533.863334695746935674.okuno.kohji@jp.panasonic.com> <20141003215830.GK26076@kib.kiev.ua> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 08:00:40 -0000 Hi, Konstantin, Thank you for your comment. And, your change is better than mine. > Do you mean that this panic is related to missed pmap_remove() ? > I doubt it, since pmap_mapdev() does not establish managed mappings. Yes, pmap_mapdev() does not establish managed mappings. But, if kernel_pmap.pm_stats.resident_count is zero, then any managed pages (for example pipe_map, exec_map, or etc.) are not able to change unmanaged status, because pmap_remove() returns without calling pmap_remove_pte(). In this result, I encounterd the panic. Could you refer the following? Regards, Kohji Okuno int vm_map_delete(vm_map_t map, vm_offset_t start, vm_offset_t end) { >> SNIP << /** this pmap_remove() does not change for mappings! **/ pmap_remove(map->pmap, entry->start, entry->end); /* * Delete the entry only after removing all pmap * entries pointing to its pages. (Otherwise, its * page frames may be reallocated, and any modify bits * will be set in the wrong object!) */ /** this calls vm_page_free_toq() and causes panic! **/ vm_map_entry_delete(map, entry); entry = next; } return (KERN_SUCCESS); } > On Fri, Oct 03, 2014 at 05:25:33PM +0900, Kohji Okuno wrote: >> Hi, >> >> At least in i386 && 9-stable, when we call pmap_mapdev() and >> pmap_unmapdev(), kernel_pmap.pm_stats.resident_count is decreased >> incorrectly. >> >> pmap_mapdev_attr()->pmap_kenter_attr(): >> In this path, kernel_pmap.pm_stats.resident_count is not increlmented. >> >> pmap_unmapdev()->kmem_free(kernel_map)->vm_map_remove()->pmap_remove(): >> But, in this path, kernel_pmap.pm_stats.resident_count is decreased in >> pmap_remove_pte(). >> >> While I called pmap_mapdev() and pmap_unmapdev() repeatedly and >> kernel_pmap.pm_stats.resident_count became `0', since pmap_remove() >> returned without removing ptes, I encountered various kernel panics. > I think you are right. > > The problem seems to be fixed in HEAD and 10, since mapdev was switched > to use kva_alloc/kva_free. I added stable@ to Cc:. > >> >> And, when I enabled INVARIANTS, I looked the following panic message. >> panic: vm_page_free_toq: freeing mapped page 0xXXXXXXXX. > Do you mean that this panic is related to missed pmap_remove() ? > I doubt it, since pmap_mapdev() does not establish managed mappings. > >> >> I think, I should change the following. >> What do you think about this? >> >> >> diff --git a/sys/i386/i386/pmap.c b/sys/i386/i386/pmap.c >> index 2adc6f8..a0998e8 100644 >> --- a/sys/i386/i386/pmap.c >> +++ b/sys/i386/i386/pmap.c >> @@ -5061,6 +5061,7 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode) >> { >> vm_offset_t va, offset; >> vm_size_t tmpsize; >> + int kmem_allocated = 0; >> >> offset = pa & PAGE_MASK; >> size = roundup(offset + size, PAGE_SIZE); >> @@ -5068,13 +5069,18 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, int mode) >> >> if (pa < KERNLOAD && pa + size <= KERNLOAD) >> va = KERNBASE + pa; >> - else >> + else { >> va = kmem_alloc_nofault(kernel_map, size); >> + kmem_allocated = 1; > > You could just do > PMAP_LOCK(kernel_pmap); > kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size); > PMAP_UNLOCK(kernel_pmap); > there. And, the same fix is needed for amd64. > >> + } >> if (!va) >> panic("pmap_mapdev: Couldn't alloc kernel virtual memory"); >> >> - for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) >> + for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) { >> pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode); >> + if (kmem_allocated) >> + kernel_pmap.pm_stats.resident_count++; >> + } >> pmap_invalidate_range(kernel_pmap, va, va + tmpsize); >> pmap_invalidate_cache_range(va, va + size); >> return ((void *)(va + offset)); >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 08:29:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C911FF60; Sat, 4 Oct 2014 08:29:48 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 546F92D7; Sat, 4 Oct 2014 08:29:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s948Thsk034440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Oct 2014 11:29:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s948Thsk034440 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s948ThYo034439; Sat, 4 Oct 2014 11:29:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Oct 2014 11:29:43 +0300 From: Konstantin Belousov To: Kohji Okuno Subject: Re: About pmap_mapdev() & pmap_unmapdev() Message-ID: <20141004082943.GN26076@kib.kiev.ua> References: <20141003.172533.863334695746935674.okuno.kohji@jp.panasonic.com> <20141003215830.GK26076@kib.kiev.ua> <20141004.170036.336251378907610162.okuno.kohji@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141004.170036.336251378907610162.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: stable@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 08:29:48 -0000 On Sat, Oct 04, 2014 at 05:00:36PM +0900, Kohji Okuno wrote: > Hi, Konstantin, > > Thank you for your comment. > And, your change is better than mine. At the end of the mail is commit candidate. I did not even compiled this. Can you test and report back, please ? > > > Do you mean that this panic is related to missed pmap_remove() ? > > I doubt it, since pmap_mapdev() does not establish managed mappings. > > Yes, pmap_mapdev() does not establish managed mappings. But, if > kernel_pmap.pm_stats.resident_count is zero, then any managed pages > (for example pipe_map, exec_map, or etc.) are not able to change > unmanaged status, because pmap_remove() returns without calling > pmap_remove_pte(). > > In this result, I encounterd the panic. Could you refer the following? Yes, kmem_back() indeed uses managed mapping. Index: amd64/amd64/pmap.c =================================================================== --- amd64/amd64/pmap.c (revision 272506) +++ amd64/amd64/pmap.c (working copy) @@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in pa = trunc_page(pa); for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode); + PMAP_LOCK(kernel_pmap); + kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size); + PMAP_UNLOCK(kernel_pmap); pmap_invalidate_range(kernel_pmap, va, va + tmpsize); pmap_invalidate_cache_range(va, va + tmpsize); return ((void *)(va + offset)); Index: i386/i386/pmap.c =================================================================== --- i386/i386/pmap.c (revision 272506) +++ i386/i386/pmap.c (working copy) @@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in size = roundup(offset + size, PAGE_SIZE); pa = pa & PG_FRAME; - if (pa < KERNLOAD && pa + size <= KERNLOAD) + if (pa < KERNLOAD && pa + size <= KERNLOAD) { va = KERNBASE + pa; - else + } else { va = kmem_alloc_nofault(kernel_map, size); + PMAP_LOCK(kernel_pmap); + kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size); + PMAP_UNLOCK(kernel_pmap); + } if (!va) panic("pmap_mapdev: Couldn't alloc kernel virtual memory"); From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 08:32:07 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7472535A; Sat, 4 Oct 2014 08:32:07 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D228B391; Sat, 4 Oct 2014 08:32:06 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id l18so3127334wgh.5 for ; Sat, 04 Oct 2014 01:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V/MW9r7ABev977cwhgOzG8m0pSxSwiwYsVi2fW+j3Ck=; b=JoMUg2zdCsCNmwtQCOPsyfENXDTLIPPUswJKy+rbgwY3n4lCm/C25FPDc/3APSxjpa tntrXQtB/pUoXuIr+XzY34K/ZLBX16e1ZFS/Rg21b++wnO6uJu1M9r2OpHaHxEJIP2cc AZNRst3WC1WH6KjB/ouJjbmxUjtfridBcHgoxecQj+4aDMRGC/cyisxK9Mfjr7sipQyY MiLDZp4Ipmy49FKK9/NnIFdXmIbMX81Y3IZ3Vr2tY3OVfkZc7ipMEM9QNLSwimndd4ny zbAFj4W8pxcc/MjoVXvJdqorJyoofKhqtd5O7mOyYN94C4ocIgpW5tE5WxA11wdt017+ A2cg== MIME-Version: 1.0 X-Received: by 10.194.2.8 with SMTP id 8mr8225061wjq.85.1412411525198; Sat, 04 Oct 2014 01:32:05 -0700 (PDT) Received: by 10.216.119.68 with HTTP; Sat, 4 Oct 2014 01:32:05 -0700 (PDT) In-Reply-To: <20141003170258.GG26076@kib.kiev.ua> References: <20141003170258.GG26076@kib.kiev.ua> Date: Sat, 4 Oct 2014 10:32:05 +0200 Message-ID: Subject: Re: i915 driver update testing From: "Ranjan1018 ." <214748mv@gmail.com> To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-x11@freebsd.org" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 08:32:07 -0000 2014-10-03 19:02 GMT+02:00 Konstantin Belousov : > Please find at the > https://kib.kiev.ua/kib/drm/i915.1.patch > a patch which provides some updates to the i915 driver. At large, this > is import of the batch of Linux commits, and as such, it is interesting > mostly as attempt to restart the race to get us more up to date Linux cod= e > imported. It might provide some bug fixes, most likely for IvyBridge. > Interesting from the development PoV is the update of the GEM i/o ioctl > code path to mimic Linux code structure. > > I am asking _only_ for reports of regressions with the patch applied, > comparing with the code which is currently in HEAD. I will not debug > any existing bugs, my goal right now is to commit this update, which is > needed for further work. I.e., only when you get an issue with the patch > applied, but cannot reproduce the problem without the patch, please > prepare a bug report. > > FYI, the driver will attach to haswell gfx, but I am not interested in > reports about this (see above paragraph). On my test box, which is Core > i7 4770S, the mode-setting and front-buffer rendering works, but Mesa > immediately cause renderer to bug out. > > Work was sponsored by The FreeBSD Foundation, both by time and hardware, > and Intel provided access to the documentation. > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" > On a Samsung ATIV Book 2 15.6=E2=80=9D Notebook - NP270E5E, specs, the patch does not works. The result of the command # kldload i915kms is a blank screen. After rebooting the notebook, in /var/log/messages I can read: Oct 4 08:12:44 ativ kernel: info: [drm] Initialized drm 1.1.0 20060810 Oct 4 08:12:45 ativ kernel: drmn0: on vgapci0 Oct 4 08:12:45 ativ kernel: info: [drm] MSI enabled 1 message(s) Oct 4 08:12:45 ativ kernel: info: [drm] AGP at 0xe0000000 256MB Oct 4 08:12:45 ativ kernel: iicbus0: on iicbb0 addr 0xff Oct 4 08:12:45 ativ kernel: iic0: on iicbus0 Oct 4 08:12:45 ativ kernel: iic1: on iicbus1 Oct 4 08:12:45 ativ kernel: iicbus2: on iicbb1 addr 0x0 Oct 4 08:12:45 ativ kernel: iic2: on iicbus2 Oct 4 08:12:45 ativ kernel: iic3: on iicbus3 Oct 4 08:12:45 ativ kernel: iicbus4: on iicbb2 addr 0x0 Oct 4 08:12:45 ativ kernel: iic4: on iicbus4 Oct 4 08:12:45 ativ kernel: iic5: on iicbus5 Oct 4 08:12:45 ativ kernel: iicbus6: on iicbb3 addr 0x0 Oct 4 08:12:45 ativ kernel: iic6: on iicbus6 Oct 4 08:12:45 ativ kernel: iic7: on iicbus7 Oct 4 08:12:45 ativ kernel: iicbus8: on iicbb4 addr 0x0 Oct 4 08:12:45 ativ kernel: iic8: on iicbus8 Oct 4 08:12:45 ativ kernel: iic9: Oct 4 08:12:45 ativ kernel: on iicbus9 Oct 4 08:12:45 ativ kernel: iicbus10: on iicbb5 addr 0x0 Oct 4 08:12:45 ativ kernel: iic10: on iicbus10 Oct 4 08:12:45 ativ kernel: iic11: on iicbus11 Oct 4 08:12:45 ativ kernel: info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). Oct 4 08:12:45 ativ kernel: info: [drm] Driver supports precise vblank timestamp query. Regards Maurizio From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 08:53:34 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EE4E9ED; Sat, 4 Oct 2014 08:53:34 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id ED503774; Sat, 4 Oct 2014 08:53:33 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile12) with ESMTP id s948rQE1014904; Sat, 4 Oct 2014 17:53:26 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili17) with ESMTP id s948rRA11458; Sat, 4 Oct 2014 17:53:27 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi11) id s948rRTe028149; Sat, 4 Oct 2014 17:53:27 +0900 Received: from localhost by lomi11.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s948rRHv028137; Sat, 4 Oct 2014 17:53:27 +0900 Date: Sat, 04 Oct 2014 17:53:26 +0900 (JST) Message-Id: <20141004.175326.766405563100788209.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com Subject: Re: About pmap_mapdev() & pmap_unmapdev() From: Kohji Okuno In-Reply-To: <20141004082943.GN26076@kib.kiev.ua> References: <20141003215830.GK26076@kib.kiev.ua> <20141004.170036.336251378907610162.okuno.kohji@jp.panasonic.com> <20141004082943.GN26076@kib.kiev.ua> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 08:53:34 -0000 Hi, Konstantin, > At the end of the mail is commit candidate. I did not even compiled this. > Can you test and report back, please ? Could you check the following? (1) should use kernel_pmap->pm_stats.resident_count ^^^ I'm sorry. My patch was wrong. (2) should use pmap_resident_count_inc() in amd64. I will test, later. In addtion, I have one question. In current and 10-stable, is vm_map_delete() called by kva_free()? If vm_map_delete() is called, this fix is needed in current and 10-stable, I think. Regards, Kohji Okuno > On Sat, Oct 04, 2014 at 05:00:36PM +0900, Kohji Okuno wrote: >> Hi, Konstantin, >> >> Thank you for your comment. >> And, your change is better than mine. > At the end of the mail is commit candidate. I did not even compiled this. > Can you test and report back, please ? > >> >> > Do you mean that this panic is related to missed pmap_remove() ? >> > I doubt it, since pmap_mapdev() does not establish managed mappings. >> >> Yes, pmap_mapdev() does not establish managed mappings. But, if >> kernel_pmap.pm_stats.resident_count is zero, then any managed pages >> (for example pipe_map, exec_map, or etc.) are not able to change >> unmanaged status, because pmap_remove() returns without calling >> pmap_remove_pte(). >> >> In this result, I encounterd the panic. Could you refer the following? > Yes, kmem_back() indeed uses managed mapping. > > Index: amd64/amd64/pmap.c > =================================================================== > --- amd64/amd64/pmap.c (revision 272506) > +++ amd64/amd64/pmap.c (working copy) > @@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in > pa = trunc_page(pa); > for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) > pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode); > + PMAP_LOCK(kernel_pmap); > + kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size); > + PMAP_UNLOCK(kernel_pmap); > pmap_invalidate_range(kernel_pmap, va, va + tmpsize); > pmap_invalidate_cache_range(va, va + tmpsize); > return ((void *)(va + offset)); > Index: i386/i386/pmap.c > =================================================================== > --- i386/i386/pmap.c (revision 272506) > +++ i386/i386/pmap.c (working copy) > @@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in > size = roundup(offset + size, PAGE_SIZE); > pa = pa & PG_FRAME; > > - if (pa < KERNLOAD && pa + size <= KERNLOAD) > + if (pa < KERNLOAD && pa + size <= KERNLOAD) { > va = KERNBASE + pa; > - else > + } else { > va = kmem_alloc_nofault(kernel_map, size); > + PMAP_LOCK(kernel_pmap); > + kernel_pmap.pm_stats.resident_count += OFF_TO_IDX(size); > + PMAP_UNLOCK(kernel_pmap); > + } > if (!va) > panic("pmap_mapdev: Couldn't alloc kernel virtual memory"); > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 09:20:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 008D5F41; Sat, 4 Oct 2014 09:20:36 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80C9393F; Sat, 4 Oct 2014 09:20:36 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s949KVR5046017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Oct 2014 12:20:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s949KVR5046017 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s949KU2q046012; Sat, 4 Oct 2014 12:20:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Oct 2014 12:20:30 +0300 From: Konstantin Belousov To: Kohji Okuno Subject: Re: About pmap_mapdev() & pmap_unmapdev() Message-ID: <20141004092030.GP26076@kib.kiev.ua> References: <20141003215830.GK26076@kib.kiev.ua> <20141004.170036.336251378907610162.okuno.kohji@jp.panasonic.com> <20141004082943.GN26076@kib.kiev.ua> <20141004.175326.766405563100788209.okuno.kohji@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141004.175326.766405563100788209.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: stable@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 09:20:37 -0000 On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote: > Hi, Konstantin, > > > At the end of the mail is commit candidate. I did not even compiled this. > > Can you test and report back, please ? > > Could you check the following? > (1) should use kernel_pmap->pm_stats.resident_count > ^^^ > I'm sorry. My patch was wrong. As well as mine. > > (2) should use pmap_resident_count_inc() in amd64. Correct. > > > I will test, later. > > In addtion, I have one question. > In current and 10-stable, is vm_map_delete() called by kva_free()? No, kva_free() only releases the vmem backing, leaving the page tables intact. This is why I only did the stable/9 patch. > If vm_map_delete() is called, this fix is needed in current and > 10-stable, I think. Updated patch below. Index: amd64/amd64/pmap.c =================================================================== --- amd64/amd64/pmap.c (revision 272506) +++ amd64/amd64/pmap.c (working copy) @@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in pa = trunc_page(pa); for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode); + PMAP_LOCK(kernel_pmap); + pmap_resident_count_inc(kernel_pmap, OFF_TO_IDX(size)); + PMAP_UNLOCK(kernel_pmap); pmap_invalidate_range(kernel_pmap, va, va + tmpsize); pmap_invalidate_cache_range(va, va + tmpsize); return ((void *)(va + offset)); Index: i386/i386/pmap.c =================================================================== --- i386/i386/pmap.c (revision 272506) +++ i386/i386/pmap.c (working copy) @@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in size = roundup(offset + size, PAGE_SIZE); pa = pa & PG_FRAME; - if (pa < KERNLOAD && pa + size <= KERNLOAD) + if (pa < KERNLOAD && pa + size <= KERNLOAD) { va = KERNBASE + pa; - else + } else { va = kmem_alloc_nofault(kernel_map, size); + PMAP_LOCK(kernel_pmap); + kernel_pmap->pm_stats.resident_count += OFF_TO_IDX(size); + PMAP_UNLOCK(kernel_pmap); + } if (!va) panic("pmap_mapdev: Couldn't alloc kernel virtual memory"); From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 10:02:57 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 605AD6C6; Sat, 4 Oct 2014 10:02:57 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B26CED4D; Sat, 4 Oct 2014 10:02:56 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id gb8so2253697lab.31 for ; Sat, 04 Oct 2014 03:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DTsb5vtlxQ9TR2c5PKjLTH5wRoxHnJkApfZkj04xBKo=; b=fbIZlHdkUXozr1KgPjaYzaEKMIYRekvxoHLJGY6IqFdZjlOJ504DmXvYnJ9KBaTJxZ pgj+9RCt5PVoZHHxnPuCFYnB5uT+kuFu18W0X3Hf+BJXkjsaLy4HWw6VlM0vWluExSVE 8kdC8dc8Dw2eIH7awNqadPG7YguPBwV48bB3Qd658dgC5GRhTazxHPdHOhwVSBdtOaaU 4adwDCD07Vl818n/gvjsYipX7eEetH8Axuz2b9wtbKui+0G8sO/Gr6MAJonox0UiQmlA PykXECuxA0tkAXzWzgnHXhy9howg5+n0QHPWByXQ9hQ202j9rUZwvAGT1Wm+T6BLrXZm VThQ== MIME-Version: 1.0 X-Received: by 10.112.26.103 with SMTP id k7mr1796690lbg.86.1412416974549; Sat, 04 Oct 2014 03:02:54 -0700 (PDT) Received: by 10.114.230.226 with HTTP; Sat, 4 Oct 2014 03:02:54 -0700 (PDT) In-Reply-To: <20141003170258.GG26076@kib.kiev.ua> References: <20141003170258.GG26076@kib.kiev.ua> Date: Sat, 4 Oct 2014 12:02:54 +0200 Message-ID: Subject: Re: i915 driver update testing From: Johannes Dieterich To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: x11@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 10:02:57 -0000 Dear all, sorry for cross-posting (I am not subscribed to x11@). Same behavior for me (i5-3320M on a Thinkpad T430s w/ Optimus support) as reported by Maurizio. When boot switches to graphics from text mode, display remains black with backlight on. I am running the experimental xorg-stack from https://trillian.chruetertee.ch/svn/ports/branches/experimental which works with an unmodified r272482 w/o problem (minus the Optimus, obviously). No entry in Xorg.0.log. /var/log/messages only contains output from consolekit, saying it waits for a native display on tty 9. Please let me know if you want me to test anything further. Best Johannes On Fri, Oct 3, 2014 at 7:02 PM, Konstantin Belousov wrote: > Please find at the > https://kib.kiev.ua/kib/drm/i915.1.patch > a patch which provides some updates to the i915 driver. At large, this > is import of the batch of Linux commits, and as such, it is interesting > mostly as attempt to restart the race to get us more up to date Linux code > imported. It might provide some bug fixes, most likely for IvyBridge. > Interesting from the development PoV is the update of the GEM i/o ioctl > code path to mimic Linux code structure. > > I am asking _only_ for reports of regressions with the patch applied, > comparing with the code which is currently in HEAD. I will not debug > any existing bugs, my goal right now is to commit this update, which is > needed for further work. I.e., only when you get an issue with the patch > applied, but cannot reproduce the problem without the patch, please > prepare a bug report. > > FYI, the driver will attach to haswell gfx, but I am not interested in > reports about this (see above paragraph). On my test box, which is Core > i7 4770S, the mode-setting and front-buffer rendering works, but Mesa > immediately cause renderer to bug out. > > Work was sponsored by The FreeBSD Foundation, both by time and hardware, > and Intel provided access to the documentation. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 11:29:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BF732A8 for ; Sat, 4 Oct 2014 11:29:19 +0000 (UTC) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11B75653 for ; Sat, 4 Oct 2014 11:29:18 +0000 (UTC) Received: from [82.113.121.206] (helo=unixarea.DDR.dd) by ms-10.1blu.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1XaNWV-0003ia-C6 for freebsd-current@freebsd.org; Sat, 04 Oct 2014 13:29:15 +0200 Date: Sat, 4 Oct 2014 13:29:11 +0200 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: sh.core in HOME of the user on system shutdown Message-ID: <20141004112911.GA1026@unixarea.DDR.dd> Reply-To: Matthias Apitz Mail-Followup-To: Matthias Apitz , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Operating-System: FreeBSD 11.0-CURRENT r269739 (i386) User-Agent: Mutt/1.5.23 (2014-03-12) X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 82.113.121.206 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 11:29:19 -0000 Hello, I run 11-CURRENT r269739 on my i386 netbook. After (clean) shutdown I always have a core file 'sh.core' in the (only) logged in users HOME; the backtrace is ofc unuseable: (gdb) bt #0 0x282152f8 in fwrite () from /lib/libc.so.7 #1 0x280978db in el_gets () from /lib/libedit.so.7 #2 0x28099746 in el_gets () from /lib/libedit.so.7 #3 0x080536a1 in ?? () #4 0x2880d300 in ?? () #5 0x08066ac8 in _CurrentRuneLocale () #6 0x53f564a4 in ?? () #7 0x00000000 in ?? () Is it a known issue or is it worth to compile the libs with -g? Thx matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: E-mail: guru@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards | en.wikipedia.org/wiki/ASCII_Ribbon_Campaign From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 11:53:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F410D6F1; Sat, 4 Oct 2014 11:53:38 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id ADF6394D; Sat, 4 Oct 2014 11:53:38 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id s94BravT018001; Sat, 4 Oct 2014 20:53:36 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili16) with ESMTP id s94BraM11070; Sat, 4 Oct 2014 20:53:36 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi16) id s94BraqG030564; Sat, 4 Oct 2014 20:53:36 +0900 Received: from localhost by lomi16.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id s94Bra5t030547; Sat, 4 Oct 2014 20:53:36 +0900 Date: Sat, 04 Oct 2014 20:53:35 +0900 (JST) Message-Id: <20141004.205335.1782700760623869892.okuno.kohji@jp.panasonic.com> To: kostikbel@gmail.com Subject: Re: About pmap_mapdev() & pmap_unmapdev() From: Kohji Okuno In-Reply-To: <20141004092030.GP26076@kib.kiev.ua> References: <20141004082943.GN26076@kib.kiev.ua> <20141004.175326.766405563100788209.okuno.kohji@jp.panasonic.com> <20141004092030.GP26076@kib.kiev.ua> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, freebsd-current@freebsd.org, okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 11:53:39 -0000 Hi Konstantin, Thank you for your prompt response. I will test and report from next monday. >> In addtion, I have one question. >> In current and 10-stable, is vm_map_delete() called by kva_free()? > No, kva_free() only releases the vmem backing, leaving the page > tables intact. This is why I only did the stable/9 patch. Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable? Could you please explain me? Regards, Kohji Okuno > On Sat, Oct 04, 2014 at 05:53:26PM +0900, Kohji Okuno wrote: >> Hi, Konstantin, >> >> > At the end of the mail is commit candidate. I did not even compiled this. >> > Can you test and report back, please ? >> >> Could you check the following? >> (1) should use kernel_pmap->pm_stats.resident_count >> ^^^ >> I'm sorry. My patch was wrong. > As well as mine. > >> >> (2) should use pmap_resident_count_inc() in amd64. > Correct. > >> >> >> I will test, later. >> >> In addtion, I have one question. >> In current and 10-stable, is vm_map_delete() called by kva_free()? > No, kva_free() only releases the vmem backing, leaving the page > tables intact. This is why I only did the stable/9 patch. > >> If vm_map_delete() is called, this fix is needed in current and >> 10-stable, I think. > > Updated patch below. > > Index: amd64/amd64/pmap.c > =================================================================== > --- amd64/amd64/pmap.c (revision 272506) > +++ amd64/amd64/pmap.c (working copy) > @@ -5040,6 +5040,9 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in > pa = trunc_page(pa); > for (tmpsize = 0; tmpsize < size; tmpsize += PAGE_SIZE) > pmap_kenter_attr(va + tmpsize, pa + tmpsize, mode); > + PMAP_LOCK(kernel_pmap); > + pmap_resident_count_inc(kernel_pmap, OFF_TO_IDX(size)); > + PMAP_UNLOCK(kernel_pmap); > pmap_invalidate_range(kernel_pmap, va, va + tmpsize); > pmap_invalidate_cache_range(va, va + tmpsize); > return ((void *)(va + offset)); > Index: i386/i386/pmap.c > =================================================================== > --- i386/i386/pmap.c (revision 272506) > +++ i386/i386/pmap.c (working copy) > @@ -5066,10 +5066,14 @@ pmap_mapdev_attr(vm_paddr_t pa, vm_size_t size, in > size = roundup(offset + size, PAGE_SIZE); > pa = pa & PG_FRAME; > > - if (pa < KERNLOAD && pa + size <= KERNLOAD) > + if (pa < KERNLOAD && pa + size <= KERNLOAD) { > va = KERNBASE + pa; > - else > + } else { > va = kmem_alloc_nofault(kernel_map, size); > + PMAP_LOCK(kernel_pmap); > + kernel_pmap->pm_stats.resident_count += OFF_TO_IDX(size); > + PMAP_UNLOCK(kernel_pmap); > + } > if (!va) > panic("pmap_mapdev: Couldn't alloc kernel virtual memory"); > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 12:37:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B56562A; Sat, 4 Oct 2014 12:37:04 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2812FD2B; Sat, 4 Oct 2014 12:37:04 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XaKaj-000O7E-Ql; Sat, 04 Oct 2014 12:21:25 +0400 Message-ID: <542FE9A7.9090208@FreeBSD.org> Date: Sat, 04 Oct 2014 16:35:51 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org Subject: HEADS UP: Merging projects/ipfw to HEAD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 12:37:04 -0000 Hi, I'm going to merge projects/ipfw branch to HEAD in the middle of next week. What has changed: Main user-visible changes are related to tables: * Tables are now identified by names, not numbers. There can be up to 65k tables with up to 63-byte long names. * Tables are now set-aware (default off), so you can switch/move them atomically with rules. * More functionality is supported (swap, lock, limits, user-level lookup, batched add/del) by generic table code. * New table types are added (flow) so you can match multiple packet fields at once. * Ability to add different type of lookup algorithms for particular table type has been added. * New table algorithms are added (cidr:hash, iface:array, number:array and flow:hash) to make certain types of lookup more effective. * Table value are now capable of holding multiple data fields for different tablearg users Some examples (see ipfw(8) manual page for the description): 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib 0:02 [2] zfscurr0# ipfw table fl2 info +++ table(fl2), set(0) +++ kindex: 0, type: flow:src-ip,proto,dst-port valtype: number, references: 0 algorithm: flow:hash items: 0, size: 280 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 0:02 [2] zfscurr0# ipfw table fl2 list +++ table(fl2), set(0) +++ 2a02:6b8::333,6,443 45000 10.0.0.92,6,80 22000 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 flow 'table(fl2)' ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" ipfw table mi_test add 10.0.0.8/30 ipfw table mi_test add 2a02:6b8:b010::1/64 25 # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 added: 1.1.1.1/32 1111 added: 2.2.2.2/32 2222 # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 exists: 2.2.2.2/32 2200 added: 4.4.4.4/32 4444 ipfw: Adding record failed: record already exists ^^^^^ Returns error but keeps inserted items # ipfw table si list +++ table(si), set(0) +++ 1.1.1.1/32 1111 2.2.2.2/32 2222 4.4.4.4/32 4444 # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 5.5.5.5/32 5555 added(reverted): 3.3.3.3/32 3333 exists: 4.4.4.4/32 4400 ignored: 5.5.5.5/32 5555 ipfw: Adding record failed: record already exists ^^^^^ Returns error and reverts added records Performance changes: * Main ipfw lock was converted to rmlock * Rule counters were separated from rule itself and made per-cpu. * Radix table entries fits into 128 bytes * struct ip_fw is now more compact so more rules will fit into 64 bytes * interface tables uses array of existing ifindexes for faster match ABI changes: All functionality supported by old ipfw(8) remains functional. Old & new binaries can work together with the following restrictions: * Tables named other than ^\d+$ are shown as table(65535) in ruleset in old binaries * I'm a bit unsure about "lookup src-port|dst-port N" case, something may be broken here. Anyway, this can be fixed for MFC Internal changes:. Changing table ids to numbers resulted in format modification for most sockopt codes. Old sopt format was compact, but very hard to extend (no versioning, inability to add more opcodes), so * All relevant opcodes were converted to TLV-based versioned IP_FW3-based codes. * The remaining opcodes were also converted to be able to eliminate all older opcodes at once * All IP_FW3 handlers uses special API instead of calling sooptcopy* directly to ease adding another communication methods * struct ip_fw is now different for kernel and userland * tablearg value has been changed to 0 to ease future extensions * table "values" are now indexes in special value array which holds extended data for given index * Batched add/delete has been added to tables code * Most changes has been done to permit batched rule addition. * interface tracking API has been added (started on demand) to permit effective interface tables operations * O(1) skipto cache, currently turned off by default at compile-time (eats 512K). * Several steps has been made towards making libipfw: * most of new functions were separated into "parse/prepare/show and actuall-do-stuff" pieces (already merged). * there are separate functions for parsing text string into "struct ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). * Probably some more less significant/forgotten features From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 15:58:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8F726D5; Sat, 4 Oct 2014 15:58:08 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64F0B2D8; Sat, 4 Oct 2014 15:58:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s94Fw3mv034704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Oct 2014 18:58:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s94Fw3mv034704 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s94Fw3X3034703; Sat, 4 Oct 2014 18:58:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 4 Oct 2014 18:58:03 +0300 From: Konstantin Belousov To: stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: About pmap_mapdev() & pmap_unmapdev() Message-ID: <20141004155803.GQ26076@kib.kiev.ua> References: <20141004082943.GN26076@kib.kiev.ua> <20141004.175326.766405563100788209.okuno.kohji@jp.panasonic.com> <20141004092030.GP26076@kib.kiev.ua> <20141004.205335.1782700760623869892.okuno.kohji@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141004.205335.1782700760623869892.okuno.kohji@jp.panasonic.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 15:58:08 -0000 On Sat, Oct 04, 2014 at 08:53:35PM +0900, Kohji Okuno wrote: > Hi Konstantin, > > Thank you for your prompt response. > I will test and report from next monday. > > >> In addtion, I have one question. > >> In current and 10-stable, is vm_map_delete() called by kva_free()? > > No, kva_free() only releases the vmem backing, leaving the page > > tables intact. This is why I only did the stable/9 patch. > > Where are PTEs allocated by pmap_mapdev() freed in current and 10-stable? > Could you please explain me? They are not freed. The removal of the vmem which covers the address space managed by corresponding ptes, allows the reuse of both KVA region and corresponding PTEs in the tables. The only concern with the resident page tables is to avoid two kva_alloc() to step over each other, and this is ensured by vmem. From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 17:48:09 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2A20BAA for ; Sat, 4 Oct 2014 17:48:09 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6CE6DF29 for ; Sat, 4 Oct 2014 17:48:09 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XaTR3-002F9I-I2>; Sat, 04 Oct 2014 19:48:01 +0200 Received: from f052009092.adsl.alicedsl.de ([78.52.9.92] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XaTR3-001yAN-Fr>; Sat, 04 Oct 2014 19:48:01 +0200 Date: Sat, 4 Oct 2014 19:47:56 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3] Message-ID: <20141004194756.5c291180.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/k/i3WyRlzbyZx0FQAt2wk77"; protocol="application/pgp-signature" X-Originating-IP: 78.52.9.92 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 17:48:09 -0000 --Sig_/k/i3WyRlzbyZx0FQAt2wk77 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Recent sources (Revision: 272529) fail to compile: [...] cc -m32 -march=3Dnative -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr= /include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2= -pipe -O3 -O3 -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=3Dgnu99 -fstac= k-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus= -int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-sw= itch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-argu= ments -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc= --- --- libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for -lctf /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.a when searching for -lctf /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lctf cc: error: linker = command failed with exit code 1 (use -v to see invocation) *** [libproc.so.3] Error code 1 make[5]: stopped in /usr/src/lib/libproc --- libproc.a --- ranlib -D libproc.a [...] oh --Sig_/k/i3WyRlzbyZx0FQAt2wk77 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUMDLQAAoJEOgBcD7A/5N8DDUIAMo0PUSDkJDGjYQTkQe4dVCL XClxU/frIZ0kRUrine+iGygUaWwJZJR5yZrVr/yoHOf1mbDUWTFOGz/jNIr2CzSG KBaNcwL6jggtQwa4mtLEZnrhqTNgVzRU6LGN3pJMh3gzw78dMmh/QVwN8MIzSzGO ZdLEs4ZItapEmPKnpFep8rsWv4dSDjEMZqWTc6JC2CC0KYkEz9v+54hf4r6CWZNV ngH+Bvdi5oOAKb/ekv9WzFK1QA41hUvihs7x4ngV36ym4VYiszJTaBudhkUeU9sa 7fXCH7NjVc2dDoHW3B14C3wsUJKgPWzyKMVFqGlbKKR40+I+xN+heDDcOyyuJkM= =5K6U -----END PGP SIGNATURE----- --Sig_/k/i3WyRlzbyZx0FQAt2wk77-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 18:33:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCB598F6 for ; Sat, 4 Oct 2014 18:33:43 +0000 (UTC) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FECA626 for ; Sat, 4 Oct 2014 18:33:43 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id fp1so1192255pdb.39 for ; Sat, 04 Oct 2014 11:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=bAgZ9H3zfsYjopFZQEjlh5Rcpf9NCjqt62nCrDRMZ8A=; b=i5vwUBijE23dtnx1MX7XgE/jwfBtuiZHnO856fimZ46ZraKfKkOzPi76aoRkgy5JtP 82HkESMRXHjeXVwu5Q/DFlke8RltsuKeta1uOmvIAkAZFQNrdlu73uaC1EV39wU+LCpd j72BXkiEnBa1o/sWenAjC3+TCeVL78wPsOxJ317i+X+M8Gh7A0c3CK7z4E/x3SD35otl YdgwKz+XGGqe4SWsRrnGBDX201hM/e/wxpilexg0fzapxUNUqdUv/5jMdKEVSa1qR4mZ gtoqnXy4JXtGkAEjpwVbpvU1bdIQkXQbpWdbjouBzF7kY8AG4Ms4Xchfi25rWs/Mirzt THog== X-Received: by 10.67.23.13 with SMTP id hw13mr14487084pad.69.1412447623224; Sat, 04 Oct 2014 11:33:43 -0700 (PDT) Received: from charmander.picturesperfect.net (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id nv1sm9374098pbc.18.2014.10.04.11.33.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Oct 2014 11:33:42 -0700 (PDT) Sender: Mark Johnston Date: Sat, 4 Oct 2014 11:33:38 -0700 From: Mark Johnston To: "O. Hartmann" Subject: Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3] Message-ID: <20141004183337.GA22999@charmander.picturesperfect.net> References: <20141004194756.5c291180.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141004194756.5c291180.ohartman@zedat.fu-berlin.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 18:33:43 -0000 On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote: > Recent sources (Revision: 272529) fail to compile: > > [...] > cc -m32 -march=native -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ > -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -O3 -O3 > -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 -fstack-protector > -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch > -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments > -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc --- --- > libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping > incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for I'm confused by this message. Are you building with -DNO_CLEAN? Do you have anything in make.conf or src.conf, especially anything that's changed since libctf was rebuilt? You might try rebuilding libctf with $ cd /usr/src $ make -C cddl/lib/libctf clean all but I'm not sure why ld is ignoring the existing libctf.so. > -lctf /usr/obj/usr/src/tmp/usr/bin/ld: skipping > incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.a when searching for > -lctf /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lctf cc: error: linker command failed > with exit code 1 (use -v to see invocation) *** [libproc.so.3] Error code 1 > > make[5]: stopped in /usr/src/lib/libproc > --- libproc.a --- > ranlib -D libproc.a > [...] > > oh From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 18:58:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E16492FE for ; Sat, 4 Oct 2014 18:58:32 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F722857 for ; Sat, 4 Oct 2014 18:58:32 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id j5so2316883qga.3 for ; Sat, 04 Oct 2014 11:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type; bh=zh6mHGd3tc612OsXrfsLnuAUYc3odimW+EFWcx7v53A=; b=oB7NVgUGFg/RBIXnKSSiQ4slsyp/+1xHu9U8fLCRvgyuCkwGHIiR49edU1/DtyWdJ5 VwIXiNGFlTbVN9Xg6TL6QFT2LWvj5klullwa4oM0WhHAG0HkRPLFZ5njFqp8UbUbO2H4 S9j6zToX+lhf67iVhfuCvj/9quR7JEvotxM9R+/EcCkiun0bm+SUeLJUL/dOgLMlRaOZ xpd71RDgeC5y8k2XmttX3qWTUrco9K89MgOqjtU5MfuVQRM5+EZ1jc9Ftgv0Qb0QvAk3 jvW6HYcvYzpTuLMv2PGcEG3qLTl1efmpQ2UD4qMuGrIz9uzhc8TtWq3OdFOWiUGK0xRl 31kA== X-Received: by 10.224.4.72 with SMTP id 8mr17767323qaq.79.1412449111694; Sat, 04 Oct 2014 11:58:31 -0700 (PDT) Received: from zhabar.attlocal.net (107-222-186-3.lightspeed.sntcca.sbcglobal.net. [107.222.186.3]) by mx.google.com with ESMTPSA id e64sm8659698qga.34.2014.10.04.11.58.30 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Oct 2014 11:58:30 -0700 (PDT) Date: Sat, 4 Oct 2014 11:58:16 -0700 From: Justin Hibbits To: FreeBSD Current Subject: bwn(4) testing Message-ID: <20141004115816.6390eb98@zhabar.attlocal.net> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; powerpc64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/U0o2NuK/vMNCv.x1=rh/mWk"; protocol="application/pgp-signature" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 18:58:33 -0000 --Sig_/U0o2NuK/vMNCv.x1=rh/mWk Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Since I don't have a machine that successfully suspends/resumes, can someone test the patch at https://reviews.freebsd.org/D802 ? It shouldn't be any functional change, just removing code duplicated by bus_generic_* functions. Thanks, Justin --Sig_/U0o2NuK/vMNCv.x1=rh/mWk Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUMENRAAoJEDDHhY43vi25S4MH/i7O/tnERu5cX79BrB9MEfwK cXGvtsXTTnCJTbIJv2bDGVy3KShZ1Dj4fiypwcZHnyrJzWMVqxv8EjnHU6y4tt4l TRfYtSt1zzKnTd2V5RmfdF/4i1z76Ta8ZgJuQapWE67c7wS3oWusdhR6JOLPSFiL iUN6R7O+8evxED/LHEtSixsaLb7O8wMqCEpERnasf8yiYZw19P/15thJ3+zxmOAU Jsui6JmtXrq7F5cGnha/BAi0msuasxwZLomlVNRg325zd0nRd+7JEusVfISU+HeR d5GJemWULatOHmk+draItNXlQZPC/ksWPYjzws6oCAX7Zxj0hdahIdocy2+Fhsc= =7ZpC -----END PGP SIGNATURE----- --Sig_/U0o2NuK/vMNCv.x1=rh/mWk-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 20:15:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2889F207 for ; Sat, 4 Oct 2014 20:15:14 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D544BF3B for ; Sat, 4 Oct 2014 20:15:13 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XaVjM-0002kI-K3 for freebsd-current@freebsd.org; Sat, 04 Oct 2014 22:15:04 +0200 Received: from c-50-172-79-238.hsd1.il.comcast.net ([50.172.79.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Oct 2014 22:15:04 +0200 Received: from ctyz1999 by c-50-172-79-238.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 04 Oct 2014 22:15:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Craig Wiesen Subject: Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support Date: Sat, 4 Oct 2014 20:10:06 +0000 (UTC) Lines: 192 Message-ID: References: <20140930015741.GA2451@michelle.fasterthan.com> <20141001013637.GD2632@michelle.fasterthan.com> <20141002050730.GA964@michelle.fasterthan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 50.172.79.238 (Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 20:15:14 -0000 Yonghyeon PYUN gmail.com> writes: > > On Wed, Oct 01, 2014 at 10:36:37AM +0900, Yonghyeon PYUN wrote: > > On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote: > > > Hi, > > > I've added support for QAC AR816x/AR817x ethernet controllers. It > > > passed my limited testing and I need more testers. You can find > > > patches from the following URLs. > > > > > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff > > > and > > > http://people.freebsd.org/~yongari/alc/alc.diff.20140930 > > > > > > pci.qurik.diff is to workaround silicon bug of AR816x. Without it > > > MSI/MSIX interrupt wouldn't work. If you just want to use > > > legacy INTx interrupt you don't have to apply it but you have to > > > tell alc(4) not to use MSI/MSIX interrupt with tunables( > > > hw.alc.msi.disable and hw.alc.msix_disable). > > > > > > alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172 > > > and E2200 controllers. It supports all hardware features except > > > RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x > > > controllers please test and report how the diff works for you. > > > Thanks. > > > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff > > http://people.freebsd.org/~yongari/alc/alc.diff.20141001 > > > > Patch updated to address link establishment issue. > > http://people.freebsd.org/~yongari/alc/alc.diff.20141002 > Patch updated again to correct wrong lock assertion. > _______________________________________________ Hi- I can add that I tested your patches on a 9.3 Stable machine. The motherboard is a GA-Z77-D3H (rev. 1.1) with onboard Atheros AR816x. I did have to apply one of the patch hunks by hand, see below. I am able to ssh into the machine, and remotely access apache/poudriere. I have not seen any problems so far. I've included a few outputs for you to examine. # uname -a FreeBSD desktop.home.org 9.3-STABLE FreeBSD 9.3-STABLE #0 r272523M: Sat Oct 4 11:50:08 CDT 2014 root@desktop.home.org:/usr/obj/usr/src/sys/SANDYBRIDGE amd64 # ifconfig -a em0: flags=8843 metric 0 mtu 1500 options=4219b ether 68:05:ca:xx:xx:xx inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255 nd6 options=29 media: Ethernet autoselect status: no carrier alc0: flags=8843 metric 0 mtu 1500 options=c319a ether 90:2b:34:xx:xx:xx inet 192.168.100.48 netmask 0xffffff00 broadcast 192.168.100.255 inet6 -redacted-%alc0 prefixlen 64 scopeid 0x4 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active I left em0 above for comparison: Rejected hunk: # cat if_alc.c.rej *************** *** 831,843 **** CSR_WRITE_4(sc, ALC_PCIE_PHYMISC2, val); } /* Disable ASPM L0S and L1. */ - cap = CSR_READ_2(sc, base + PCIER_LINK_CAP); if ((cap & PCIEM_LINK_CAP_ASPM) != 0) { - ctl = CSR_READ_2(sc, base + PCIER_LINK_CTL); if ((ctl & PCIEM_LINK_CTL_RCB) != 0) sc->alc_rcb = DMA_CFG_RCB_128; if (bootverbose) - device_printf(dev, "RCB %u bytes\n", sc->alc_rcb == DMA_CFG_RCB_64 ? 64 : 128); state = ctl & PCIEM_LINK_CTL_ASPMC; if (state & PCIEM_LINK_CTL_ASPMC_L0S) --- 1279,1291 ---- CSR_WRITE_4(sc, ALC_PCIE_PHYMISC2, val); } /* Disable ASPM L0S and L1. */ + cap = CSR_READ_2(sc, sc->alc_expcap + PCIER_LINK_CAP); if ((cap & PCIEM_LINK_CAP_ASPM) != 0) { + ctl = CSR_READ_2(sc, sc->alc_expcap + PCIER_LINK_CTL); if ((ctl & PCIEM_LINK_CTL_RCB) != 0) sc->alc_rcb = DMA_CFG_RCB_128; if (bootverbose) + device_printf(sc->alc_dev, "RCB %u bytes\n", sc->alc_rcb == DMA_CFG_RCB_64 ? 64 : 128); state = ctl & PCIEM_LINK_CTL_ASPMC; if (state & PCIEM_LINK_CTL_ASPMC_L0S) >From verbose boot log: pcib5: irq 18 at device 28.6 on pci0 pcib0: allocated type 4 (0xd000-0xdfff) for rid 1c of pcib5 pcib0: allocated type 3 (0xf7900000-0xf79fffff) for rid 20 of pcib5 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xd000-0xdfff pcib5: memory decode 0xf7900000-0xf79fffff pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x1969, dev=0x1091, revid=0x10 domain=0, bus=5, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages, 64 bit, vector masks MSI-X supports 16 messages in map 0x10 map[10]: type Memory, range 64, base 0xf7900000, size 18, enabled pcib5: allocated memory range (0xf7900000-0xf793ffff) for rid 10 of pci0:5:0:0 map[18]: type I/O Port, range 32, base 0xd000, size 7, enabled pcib5: allocated I/O port range (0xd000-0xd07f) for rid 18 of pci0:5:0:0 pcib5: matched entry for 5.0.INTA pcib5: slot 0 INTA hardwired to IRQ 18 alc0: port 0xd000-0xd07f mem 0xf7900000-0xf793ffff irq 18 at device 0.0 on pci5 alc0: PCI device revision : 0x0010 alc0: Chip id/revision : 0xc002 alc0: AR816x revision : 0x2 alc0: 11776 Tx FIFO, 12032 Rx FIFO alc0: Read request size : 512 bytes. alc0: TLP payload size : 128 bytes. alc0: MSIX count : 16 alc0: MSI count : 16 alc0: attempting to allocate 1 MSI-X vectors (16 supported) msi: routing MSI-X IRQ 269 to local APIC 0 vector 66 alc0: using IRQ 269 for MSI-X alc0: Using 1 MSIX message(s). miibus0: on alc0 atphy0: PHY 0 on miibus0 atphy0: OUI 0x00c82e, model 0x0007, rev. 9 atphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT- FDX, 1000baseT-FDX-master, auto, auto- flow alc0: bpf attached alc0: Ethernet address: 90:2b:34:xx:xx:xx Excerpt from: # pciconf -lv pcib5@pci0:0:28:6: class=0x060400 card=0x50011458 chip=0x1e1c8086 rev=0xc4 hdr=0x01 vendor = 'Intel Corporation' device = 'Panther Point PCI Express Root Port 7' class = bridge subclass = PCI-PCI alc0@pci0:5:0:0: class=0x020000 card=0xe0001458 chip=0x10911969 rev=0x10 hdr=0x00 vendor = 'Atheros Communications' class = network subclass = ethernet Thanks for your efforts! Craig From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 20:24:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB69738A; Sat, 4 Oct 2014 20:24:40 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3333FFF; Sat, 4 Oct 2014 20:24:40 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XaVsc-002Yeq-Fn>; Sat, 04 Oct 2014 22:24:38 +0200 Received: from f052009092.adsl.alicedsl.de ([78.52.9.92] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XaVsc-002Bk4-C0>; Sat, 04 Oct 2014 22:24:38 +0200 Date: Sat, 4 Oct 2014 22:24:31 +0200 From: "O. Hartmann" To: Mark Johnston Subject: Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3] Message-ID: <20141004222431.5c58c4c0.ohartman@zedat.fu-berlin.de> In-Reply-To: <20141004183337.GA22999@charmander.picturesperfect.net> References: <20141004194756.5c291180.ohartman@zedat.fu-berlin.de> <20141004183337.GA22999@charmander.picturesperfect.net> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/a8awB=aDpsY45j_+HcZ.rTF"; protocol="application/pgp-signature" X-Originating-IP: 78.52.9.92 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 20:24:41 -0000 --Sig_/a8awB=aDpsY45j_+HcZ.rTF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sat, 4 Oct 2014 11:33:38 -0700 Mark Johnston schrieb: > On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote: > > Recent sources (Revision: 272529) fail to compile: > >=20 > > [...] > > cc -m32 -march=3Dnative -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32= /usr/include/ > > -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 = -O2 -pipe -O3 > > -O3 -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=3Dgnu99 > > -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty= -body > > -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compa= re > > -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-e= num-conversion > > -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parenthes= es > > -Qunused-arguments -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o= --- > > all_subdir_libproc --- --- libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bi= n/ld: skipping > > incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for >=20 > I'm confused by this message. Are you building with -DNO_CLEAN? Do you > have anything in make.conf or src.conf, especially anything that's > changed since libctf was rebuilt? I do not build with -DNO_CLEAN. I use a script which kills everything in /u= sr/obj/ and build then from scratch.=20 >=20 > You might try rebuilding libctf with >=20 > $ cd /usr/src > $ make -C cddl/lib/libctf clean all I can build libctf.so that way, also installation is no problem, but next t= ime when I buildworld, I run into the same situation. >=20 > but I'm not sure why ld is ignoring the existing libctf.so. Me either. >=20 > > -lctf /usr/obj/usr/src/tmp/usr/bin/ld: skipping > > incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.a when searching for > > -lctf /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lctf cc: error: lin= ker command > > failed with exit code 1 (use -v to see invocation) *** [libproc.so.3] E= rror code 1 > >=20 > > make[5]: stopped in /usr/src/lib/libproc > > --- libproc.a --- > > ranlib -D libproc.a > > [...] > >=20 > > oh --Sig_/a8awB=aDpsY45j_+HcZ.rTF Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUMFeFAAoJEOgBcD7A/5N8BE8IAN9va3dCGwCv5h5P3+y4k3SV Qj5pLF+PumCA6jKoguJHviH4KgNfPaVhhKoaxN5Lg+MStqE91vvATguRzu6Ay69A z/Vufi2tnzIrz1Lr1kf0hzUZL+OqgPl+7z1EzmS4Z3VvX5bFE6UZ0icwFknKeQJU a3O3sClu3QrbikTXt2dbDZgKegHgbR4n9TLG2RD8od4SohLGw3KZVJc0wfzYuAUx Dnu6xtkBSN8wnCqZNHuF0R3ocEJ43vFFyf0qXJrut9VnGnvVvBG36+pJrOSiXpr/ KY1l/WzGUCd5a7/DCH1Z7FbMF16r/BS3rwVI3B4taSeoz+s5fxU2V/0EevePCWQ= =g9FV -----END PGP SIGNATURE----- --Sig_/a8awB=aDpsY45j_+HcZ.rTF-- From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 20:39:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7139D81C; Sat, 4 Oct 2014 20:39:40 +0000 (UTC) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C30011BC; Sat, 4 Oct 2014 20:39:39 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id q1so2629380lam.22 for ; Sat, 04 Oct 2014 13:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iE1IWcGc97p/cTJDjUN6c3IALM+PK5Ebs5Aei7ppurQ=; b=GYI0H+aL6Wm0BLLIBFZ+tZbBs/otdutfYEWAeEEQ7BJG4hhIZvz8dArsynNq4BuzjT UVy1svMRv+8s6j89UnlBbypqGKbPc18l2clp9bvPo79eHOyeC2+e16C0LSbMbmHJDfF5 GRnkRcwacjbteCiFFX8tE/umyPjNYPoLDzoyVvyHJkyToZzn8XSBzxiZnaGSH5g8L33x aKkxFLQok5QfKRRu4e2/f+rkWD6E3fXZ8KlYQKBJviWfuwUdzZRE+Vvv3+T7LlFLyijV ZD+HrJGgkjz6K+gsi/2/htwWWckdVrpNE3ipKLATYN1yTASXpLTyNbSYEerE2+sfh3yI FAKA== MIME-Version: 1.0 X-Received: by 10.112.198.131 with SMTP id jc3mr13431611lbc.42.1412455177737; Sat, 04 Oct 2014 13:39:37 -0700 (PDT) Received: by 10.25.21.197 with HTTP; Sat, 4 Oct 2014 13:39:37 -0700 (PDT) In-Reply-To: <20141004183337.GA22999@charmander.picturesperfect.net> References: <20141004194756.5c291180.ohartman@zedat.fu-berlin.de> <20141004183337.GA22999@charmander.picturesperfect.net> Date: Sat, 4 Oct 2014 16:39:37 -0400 Message-ID: Subject: Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3] From: Ryan Stone To: Mark Johnston Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD CURRENT , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 20:39:40 -0000 On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston wrote: > On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote: >> Recent sources (Revision: 272529) fail to compile: >> >> [...] >> cc -m32 -march=native -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ >> -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -O3 -O3 >> -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 -fstack-protector >> -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int >> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value >> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch >> -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments >> -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc --- --- >> libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping >> incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for > > I'm confused by this message. Are you building with -DNO_CLEAN? Do you > have anything in make.conf or src.conf, especially anything that's > changed since libctf was rebuilt? > > You might try rebuilding libctf with > > $ cd /usr/src > $ make -C cddl/lib/libctf clean all > > but I'm not sure why ld is ignoring the existing libctf.so. The failure is coming while building the lib32 compat libraries. Are we not currently building a lib32 libctf.so? From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 21:59:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EBD9897 for ; Sat, 4 Oct 2014 21:59:21 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D25E5B1F for ; Sat, 4 Oct 2014 21:59:20 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XaTMs-00057m-9l; Sat, 04 Oct 2014 21:43:42 +0400 Message-ID: <54306D39.3020306@FreeBSD.org> Date: Sun, 05 Oct 2014 01:57:13 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Mike." , freebsd-current@freebsd.org Subject: Re: Looping during boot-up process in FreeBSD-11 current References: <201409281152140359.008FD377@smtp.24cl.home> <201409281153050191.00909A0F@smtp.24cl.home> <4821117AE9E7452FB73D452060B1E4CF@multiplay.co.uk> <201409291603440911.019119CE@smtp.24cl.home> <20140929210142.M26034@beckpeccoz.com> <201409301044110291.0060BD57@smtp.24cl.home> <20140930171721.M83701@beckpeccoz.com> <201409301802450173.011AD57C@smtp.24cl.home> In-Reply-To: <201409301802450173.011AD57C@smtp.24cl.home> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 21:59:21 -0000 On 01.10.2014 02:02, Mike. wrote: > On 9/30/2014 at 7:25 PM José Pérez Arauzo wrote: > > > |[snip] > |Try the 271146, > |[snip] > ============= This might be related with r271207. Can you try r271206 (or any recent HEAD with reverted r271207) ? > > > I installed the 10.0 release CD. > > Then (after installing pkg, svn, etc.): > > > cd /usr/src > > svn update -r271146 > > make buildkernel > > make installkernel > > reboot > > > I got to the login prompt, so it did not exhibit the looping issue > I've experienced. > > /usr/src/UPDATING shows 20140708 p7 as the latest patch for the > source. > > dmesg (with boot -v) follows: > (note: when I boot 11.0-current with boot -v, the looping begins > right after the place where the "GEOM: new disk cd0" line appears in > the dmesg below) > > > > > Copyright (c) 1992-2014 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 10.0-RELEASE-p7 #0 r271146: Tue Sep 30 16:38:12 EDT 2014 > root@a31pf:/usr/obj/usr/src/sys/GENERIC i386 > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > Preloaded elf kernel "/boot/kernel/kernel" at 0xc1678000. > Calibrating TSC clock ... TSC clock: 1698592154 Hz > CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.59-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0xf24 Family = 0xf Model = > 0x2 Stepping = 4 > Features=0x3febf9ff E,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM> > > Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 > entries > Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries > 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 > byte line size > Trace cache: 12K-uops, 8-way set associative > 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 > byte line size > real memory = 1073741824 (1024 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000001826000 - 0x000000003ee0efff, 1029607424 bytes (251369 > pages) > avail memory = 1029230592 (981 MB) > XEN: CPU 0 has VCPU ID 4294967295 > bios32: Found BIOS32 Service Directory header at 0xc00f7030 > bios32: Entry = 0xfd7e0 (c00fd7e0) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xfd770+0x18e > pnpbios: Found PnP BIOS data at 0xc00f7090 > pnpbios: Entry = f0000:9d76 Rev = 1.0 > pnpbios: Event flag at 4b4 > Other BIOS signatures found: > ULE: setup cpu 0 > wlan: <802.11 Link Layer> > snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] > c=0x000003ff [1024] > feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 > feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 > Hardware, VIA Nehemiah Padlock RNG: VIA Padlock RNG not present > Hardware, Intel IvyBridge+ RNG: RDRAND is not present > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > nfslock: pseudo-device > null: > Falling back to random adaptor > random: initialized > VESA: INT 0x10 vector 0xc000:0x206c > VESA: information block > 0000 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 > 0010 00 01 ff 03 00 01 19 01 00 01 2f 01 00 01 34 01 > 0020 00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 > 0030 94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 > 0040 b2 01 b3 01 b4 01 b5 01 b6 01 c2 01 c3 01 c4 01 > 0050 c5 01 c6 01 00 01 83 01 84 01 85 01 86 01 01 01 > 0060 10 01 11 01 12 01 21 01 03 01 13 01 14 01 15 01 > 0070 22 01 05 01 16 01 17 01 18 01 23 01 07 01 19 01 > 0080 1a 01 1b 01 24 01 40 01 41 01 42 01 43 01 44 01 > 0090 72 01 73 01 74 01 75 01 76 01 ff ff 00 00 00 00 > 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0100 41 54 49 20 4d 4f 42 49 4c 49 54 59 20 52 41 44 > 0110 45 4f 4e 20 37 35 30 30 00 41 54 49 20 54 65 63 > 0120 68 6e 6f 6c 6f 67 69 65 73 20 49 6e 63 2e 00 50 > 0130 37 20 20 00 30 31 2e 30 30 00 00 00 00 00 00 00 > 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > VESA: 60 mode(s) found > VESA: v2.0, 65472k memory, flags:0x1, mode table:0xe3ee6022 (1000022) > VESA: ATI MOBILITY RADEON 7500 > VESA: ATI Technologies Inc. P7 01.00 > io: > hpt27xx: RocketRAID 27xx controller driver v1.1 > hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 > hptnr: R750/DC7280 controller driver v1.0 > ACPI: RSDP 0xf7060 00024 (v02 IBM ) > ACPI: XSDT 0x3ff72c6d 00044 (v01 IBM TP-1G 00001120 LTP > 00000000) > ACPI: FACP 0x3ff72d00 00081 (v01 IBM TP-1G 00001120 IBM > 00000001) > ACPI: DSDT 0x3ff72de7 0B06F (v01 IBM TP-1G 00001120 MSFT > 0100000D) > ACPI: FACS 0x3ff7f000 00040 > ACPI: SSDT 0x3ff72db4 00033 (v01 IBM TP-1G 00001120 MSFT > 0100000D) > ACPI: ECDT 0x3ff7de56 00052 (v01 IBM TP-1G 00001120 IBM > 00000001) > ACPI: BOOT 0x3ff7dfd8 00028 (v01 IBM TP-1G 00001120 LTP > 00000001) > acpi0: on motherboard > ACPI: All ACPI Tables successfully acquired > acpi_ec0: port 0x62,0x66 on > acpi0 > pci_open(1): mode 1 addr port (0x0cf8) is 0x80010014 > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=00] is there > (id=1a308086) > pcibios: BIOS version 2.10 > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xe3f17000 pa 0x1000 > atpic: Programming IRQ9 as level/low > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 3ff00000 (3) failed > cpu0: on acpi0 > cpu0: switching to generic Cx mode > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us, > adjustment 0.500000000s) > Event timer "RTC" frequency 32768 Hz quality 0 > ACPI timer: 0/15 0/15 0/15 0/15 0/15 0/15 0/15 0/15 0/15 0/15 -> 0 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on > acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Validation 0 11 N 0 3 4 5 6 7 9 10 11 > After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Validation 0 11 N 0 3 4 5 6 7 9 10 11 > After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Validation 0 11 N 0 3 4 5 6 7 9 10 11 > After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Validation 0 11 N 0 3 4 5 6 7 9 10 11 > After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Validation 0 11 N 0 3 4 5 6 7 9 10 11 > After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 > Validation 0 255 N 0 3 4 5 6 7 9 10 11 > After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 > Validation 0 255 N 0 3 4 5 6 7 9 10 11 > After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 > Validation 0 255 N 0 3 4 5 6 7 9 10 11 > After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > acpi_lid0: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pcib0: decoding 4 range 0-0xcf7 > pcib0: decoding 4 range 0xd00-0xffff > pcib0: decoding 3 range 0xa0000-0xbffff > pcib0: decoding 3 range 0xd4000-0xd7fff > pcib0: decoding 3 range 0xd8000-0xdbfff > pcib0: decoding 3 range 0x40000000-0xfebfffff > ACPI: Found matching pin for 0.29.INTA at func 0: 11 > ACPI: Found matching pin for 0.29.INTB at func 1: 11 > ACPI: Found matching pin for 0.29.INTC at func 2: 11 > ACPI: Found matching pin for 0.31.INTA at func 1: 255 > ACPI: Found matching pin for 0.31.INTB at func 3: 11 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x8086, dev=0x1a30, revid=0x04 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size > 26, enabled > pcib0: allocated type 3 (0xe0000000-0xe3ffffff) for rid 10 of > pci0:0:0:0 > found-> vendor=0x8086, dev=0x1a31, revid=0x04 > domain=0, bus=0, slot=1, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) > lattimer=0x60 (2880 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 > ns) > found-> vendor=0x8086, dev=0x2482, revid=0x02 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > map[20]: type I/O Port, range 32, base 0x1800, size 5, enabled > pcib0: allocated type 4 (0x1800-0x181f) for rid 20 of pci0:0:29:0 > pcib0: matched entry for 0.29.INTA (src \134_SB_.LNKA:0) > pcib0: slot 29 INTA routed to irq 11 via \134_SB_.LNKA > found-> vendor=0x8086, dev=0x2484, revid=0x02 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled > pcib0: allocated type 4 (0x1820-0x183f) for rid 20 of pci0:0:29:1 > pcib0: matched entry for 0.29.INTB (src \134_SB_.LNKD:0) > pcib0: slot 29 INTB routed to irq 11 via \134_SB_.LNKD > found-> vendor=0x8086, dev=0x2487, revid=0x02 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=11 > map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled > pcib0: allocated type 4 (0x1840-0x185f) for rid 20 of pci0:0:29:2 > pcib0: matched entry for 0.29.INTC (src \134_SB_.LNKC:0) > pcib0: slot 29 INTC routed to irq 11 via \134_SB_.LNKC > found-> vendor=0x8086, dev=0x2448, revid=0x42 > domain=0, bus=0, slot=30, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 > ns) > found-> vendor=0x8086, dev=0x248c, revid=0x02 > domain=0, bus=0, slot=31, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x248a, revid=0x02 > domain=0, bus=0, slot=31, func=1 > class=01-01-8a, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:31:1 > pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:31:1 > pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:31:1 > pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:31:1 > map[20]: type I/O Port, range 32, base 0x1860, size 4, enabled > pcib0: allocated type 4 (0x1860-0x186f) for rid 20 of pci0:0:31:1 > map[24]: type Memory, range 32, base 0, size 10, memory disabled > found-> vendor=0x8086, dev=0x2483, revid=0x02 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled > pcib0: allocated type 4 (0x1880-0x189f) for rid 20 of pci0:0:31:3 > pcib0: matched entry for 0.31.INTB (src \134_SB_.LNKB:0) > pcib0: slot 31 INTB routed to irq 11 via \134_SB_.LNKB > found-> vendor=0x8086, dev=0x2485, revid=0x02 > domain=0, bus=0, slot=31, func=5 > class=04-01-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > map[10]: type I/O Port, range 32, base 0x1c00, size 8, enabled > pcib0: allocated type 4 (0x1c00-0x1cff) for rid 10 of pci0:0:31:5 > map[14]: type I/O Port, range 32, base 0x18c0, size 6, enabled > pcib0: allocated type 4 (0x18c0-0x18ff) for rid 14 of pci0:0:31:5 > pcib0: matched entry for 0.31.INTB (src \134_SB_.LNKB:0) > pcib0: slot 31 INTB routed to irq 11 via \134_SB_.LNKB > found-> vendor=0x8086, dev=0x2486, revid=0x02 > domain=0, bus=0, slot=31, func=6 > class=07-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > map[10]: type I/O Port, range 32, base 0x2400, size 8, enabled > pcib0: allocated type 4 (0x2400-0x24ff) for rid 10 of pci0:0:31:6 > map[14]: type I/O Port, range 32, base 0x2000, size 7, enabled > pcib0: allocated type 4 (0x2000-0x207f) for rid 14 of pci0:0:31:6 > pcib0: matched entry for 0.31.INTB (src \134_SB_.LNKB:0) > pcib0: slot 31 INTB routed to irq 11 via \134_SB_.LNKB > agp0: on hostb0 > agp0: allocating GATT for aperture of size 64M > pcib1: at device 1.0 on pci0 > pcib1: allocating non-ISA range 0x3000-0x30ff > pcib0: allocated type 4 (0x3000-0x30ff) for rid 1c of pcib1 > pcib1: allocating non-ISA range 0x3400-0x34ff > pcib0: allocated type 4 (0x3400-0x34ff) for rid 1c of pcib1 > pcib1: allocating non-ISA range 0x3800-0x38ff > pcib0: allocated type 4 (0x3800-0x38ff) for rid 1c of pcib1 > pcib1: allocating non-ISA range 0x3c00-0x3cff > pcib0: allocated type 4 (0x3c00-0x3cff) for rid 1c of pcib1 > pcib0: allocated type 3 (0xd0100000-0xd01fffff) for rid 20 of pcib1 > pcib0: allocated type 3 (0xe8000000-0xefffffff) for rid 24 of pcib1 > pcib1: domain 0 > pcib1: secondary bus 1 > pcib1: subordinate bus 1 > pcib1: I/O decode 0x3000-0x3fff > pcib1: memory decode 0xd0100000-0xd01fffff > pcib1: prefetched decode 0xe8000000-0xefffffff > pcib1: special decode ISA, VGA > ACPI: Found matching pin for 1.0.INTA at func 0: 11 > pci1: on pcib1 > pci1: domain=0, physical bus=1 > found-> vendor=0x1002, dev=0x4c58, revid=0x00 > domain=0, bus=1, slot=0, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0387, statreg=0x02b0, cachelnsz=8 (dwords) > lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 > ns) > intpin=a, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Prefetchable Memory, range 32, base 0xe8000000, size > 27, enabled > pcib1: allocated prefetch range (0xe8000000-0xefffffff) for rid 10 of > pci0:1:0:0 > map[14]: type I/O Port, range 32, base 0x3000, size 8, enabled > pcib1: allocated I/O port range (0x3000-0x30ff) for rid 14 of > pci0:1:0:0 > map[18]: type Memory, range 32, base 0xd0100000, size 16, enabled > pcib1: allocated memory range (0xd0100000-0xd010ffff) for rid 18 of > pci0:1:0:0 > pcib1: matched entry for 1.0.INTA (src \134_SB_.LNKA:0) > pcib1: slot 0 INTA routed to irq 11 via \134_SB_.LNKA > vgapci0: port 0x3000-0x30ff mem > 0xe8000000-0xefffffff,0xd0100000-0xd010ffff irq 11 at device 0.0 on > pci1 > vgapci0: Boot video device > uhci0: port > 0x1800-0x181f irq 11 at device 29.0 on pci0 > usbus0 on uhci0 > uhci0: usbpf: Attached > uhci1: port > 0x1820-0x183f irq 11 at device 29.1 on pci0 > usbus1 on uhci1 > uhci1: usbpf: Attached > uhci2: port > 0x1840-0x185f irq 11 at device 29.2 on pci0 > usbus2 on uhci2 > uhci2: usbpf: Attached > pcib2: at device 30.0 on pci0 > pcib2: allocating non-ISA range 0x4000-0x40ff > pcib0: allocated type 4 (0x4000-0x40ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x4400-0x44ff > pcib0: allocated type 4 (0x4400-0x44ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x4800-0x48ff > pcib0: allocated type 4 (0x4800-0x48ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x4c00-0x4cff > pcib0: allocated type 4 (0x4c00-0x4cff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x5000-0x50ff > pcib0: allocated type 4 (0x5000-0x50ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x5400-0x54ff > pcib0: allocated type 4 (0x5400-0x54ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x5800-0x58ff > pcib0: allocated type 4 (0x5800-0x58ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x5c00-0x5cff > pcib0: allocated type 4 (0x5c00-0x5cff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x6000-0x60ff > pcib0: allocated type 4 (0x6000-0x60ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x6400-0x64ff > pcib0: allocated type 4 (0x6400-0x64ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x6800-0x68ff > pcib0: allocated type 4 (0x6800-0x68ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x6c00-0x6cff > pcib0: allocated type 4 (0x6c00-0x6cff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x7000-0x70ff > pcib0: allocated type 4 (0x7000-0x70ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x7400-0x74ff > pcib0: allocated type 4 (0x7400-0x74ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x7800-0x78ff > pcib0: allocated type 4 (0x7800-0x78ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x7c00-0x7cff > pcib0: allocated type 4 (0x7c00-0x7cff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x8000-0x80ff > pcib0: allocated type 4 (0x8000-0x80ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x8400-0x84ff > pcib0: allocated type 4 (0x8400-0x84ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x8800-0x88ff > pcib0: allocated type 4 (0x8800-0x88ff) for rid 1c of pcib2 > pcib2: allocating non-ISA range 0x8c00-0x8cff > pcib0: allocated type 4 (0x8c00-0x8cff) for rid 1c of pcib2 > pcib0: allocated type 3 (0xd0200000-0xdfffffff) for rid 20 of pcib2 > pcib0: allocated type 3 (0xf0000000-0xf7ffffff) for rid 24 of pcib2 > pcib2: domain 0 > pcib2: secondary bus 2 > pcib2: subordinate bus 8 > pcib2: I/O decode 0x4000-0x8fff > pcib2: memory decode 0xd0200000-0xdfffffff > pcib2: prefetched decode 0xf0000000-0xf7ffffff > pcib2: special decode ISA, subtractive > ACPI: Found matching pin for 2.0.INTA at func 0: 11 > ACPI: Found matching pin for 2.0.INTB at func 1: 11 > ACPI: Found matching pin for 2.0.INTC at func 2: 11 > ACPI: Found matching pin for 2.8.INTA at func 0: 11 > pci2: on pcib2 > pci2: domain=0, physical bus=2 > found-> vendor=0x1180, dev=0x0476, revid=0xa8 > domain=0, bus=2, slot=0, func=0 > class=06-07-00, hdrtype=0x02, mfdev=1 > cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 > (1750 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0x50000000, size 12, enabled > pcib0: allocated type 3 (0x50000000-0x50000fff) for rid 10 of > pci0:2:0:0 > pcib2: matched entry for 2.0.INTA (src \134_SB_.LNKA:0) > pcib2: slot 0 INTA routed to irq 11 via \134_SB_.LNKA > found-> vendor=0x1180, dev=0x0476, revid=0xa8 > domain=0, bus=2, slot=0, func=1 > class=06-07-00, hdrtype=0x02, mfdev=1 > cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x07 > (1750 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0x50100000, size 12, enabled > pcib0: allocated type 3 (0x50100000-0x50100fff) for rid 10 of > pci0:2:0:1 > pcib2: matched entry for 2.0.INTB (src \134_SB_.LNKB:0) > pcib2: slot 0 INTB routed to irq 11 via \134_SB_.LNKB > found-> vendor=0x1180, dev=0x0552, revid=0x00 > domain=0, bus=2, slot=0, func=2 > class=0c-00-10, hdrtype=0x00, mfdev=1 > cmdreg=0x0106, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 > (1000 ns) > intpin=c, irq=11 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xd0201000, size 11, enabled > pcib2: allocated memory range (0xd0201000-0xd02017ff) for rid 10 of > pci0:2:0:2 > pcib2: matched entry for 2.0.INTC (src \134_SB_.LNKC:0) > pcib2: slot 0 INTC routed to irq 11 via \134_SB_.LNKC > found-> vendor=0x8086, dev=0x1031, revid=0x42 > domain=0, bus=2, slot=8, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0117, statreg=0x0290, cachelnsz=8 (dwords) > lattimer=0x42 (1980 ns), mingnt=0x08 (2000 ns), maxlat=0x38 > (14000 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xd0200000, size 12, enabled > pcib2: allocated memory range (0xd0200000-0xd0200fff) for rid 10 of > pci0:2:8:0 > map[14]: type I/O Port, range 32, base 0x8000, size 6, enabled > pcib2: allocated I/O port range (0x8000-0x803f) for rid 14 of > pci0:2:8:0 > pcib2: matched entry for 2.8.INTA (src \134_SB_.LNKE:0) > pcib2: slot 8 INTA routed to irq 11 via \134_SB_.LNKE > cbb0: mem 0x50000000-0x50000fff irq 11 > at device 0.0 on pci2 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: PCI Configuration space: > 0x00: 0x04761180 0x02100107 0x060700a8 0x00824000 > 0x10: 0x50000000 0x020000dc 0xb0050302 0xfffff000 > 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc > 0x30: 0x00000000 0xfffffffc 0x00000000 0x0700010b > 0x40: 0x01851014 0x00000001 0x00000000 0x00000000 > 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x80: 0x04800001 0x00000000 0x04630464 0x00000000 > 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xa0: 0x008a0000 0x00000000 0x00f00000 0x00000000 > 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc0: 0x01851014 0x00000000 0x00000000 0x00000000 > 0xd0: 0x00000000 0x00000000 0x00000000 0xfe0a0001 > 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 > 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 > cbb1: mem 0x50100000-0x50100fff irq 11 > at device 0.1 on pci2 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > cbb1: PCI Configuration space: > 0x00: 0x04761180 0x02100107 0x060700a8 0x00824000 > 0x10: 0x50100000 0x020000dc 0xb0080602 0xfffff000 > 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc > 0x30: 0x00000000 0xfffffffc 0x00000000 0x0700020b > 0x40: 0x01851014 0x00000001 0x00000000 0x00000000 > 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x80: 0x04800001 0x00000000 0x04630464 0x00000000 > 0x90: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xa0: 0x008a0000 0x00000000 0x00f00000 0x00000000 > 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc0: 0x01851014 0x00000000 0x00000000 0x00000000 > 0xd0: 0x00000000 0x00000000 0x00000000 0xfe0a0001 > 0xe0: 0x24c04000 0x00000000 0x00000000 0x00000000 > 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 > pci2: at device 0.2 (no driver attached) > fxp0: port 0x8000-0x803f > mem 0xd0200000-0xd0200fff irq 11 at device 8.0 on pci2 > fxp0: using memory space register mapping > fxp0: PCI IDs: 8086 1031 1014 0209 0042 > fxp0: Dynamic Standby mode is disabled > miibus0: on fxp0 > inphy0: PHY 1 on miibus0 > inphy0: OUI 0x005500, model 0x0033, rev. 0 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, > auto-flow > fxp0: bpf attached > fxp0: Ethernet address: 00:0e:9b:2c:c7:f6 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on > pci0 > ata0: at channel 0 on atapci0 > ata1: at channel 1 on atapci0 > pci0: at device 31.3 (no driver attached) > pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff irq 11 > at device 31.5 on pci0 > pcm0: > pcm0: Codec features headphone, 6 bit master volume, Analog Devices > Phat Stereo > pcm0: Primary codec extended features variable rate PCM > pcm0: ac97 codec dac ready count: 0 > pcm0: Mixer "vol": > pcm0: Mixer "pcm": > pcm0: Mixer "speaker": > pcm0: Mixer "line": > pcm0: Mixer "mic": > pcm0: Mixer "cd": > pcm0: Mixer "rec": > pcm0: Mixer "igain": > pcm0: Mixer "line1": > pcm0: Mixer "phin": > pcm0: Mixer "phout": > pcm0: Mixer "video": > pci0: at device 31.6 (no driver > attached) > acpi_tz0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0047 > atkbd: keyboard ID 0x54ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > atkbd0: [GIANT-LOCKED] > psm0: unable to allocate IRQ > psmcpnp0: irq 12 on acpi0 > psm0: current command byte:0047 > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons > psm0: config:00004000, flags:00000008, packet size:3 > psm0: syncmask:c0, syncbits:00 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > uart0: fast interrupt > ppc0: using extended I/O port range > battery0: on acpi0 > acpi_acad0: on acpi0 > ex_isa_identify() > ahc_isa_identify 0: ioport 0xc00 alloc failed > ahc_isa_identify 1: ioport 0x1c00 alloc failed > ahc_isa_identify 2: ioport 0x2c00 alloc failed > ahc_isa_identify 3: ioport 0x3c00 alloc failed > ahc_isa_identify 4: ioport 0x4c00 alloc failed > ahc_isa_identify 5: ioport 0x5c00 alloc failed > ahc_isa_identify 6: ioport 0x6c00 alloc failed > ahc_isa_identify 7: ioport 0x7c00 alloc failed > ahc_isa_identify 8: ioport 0x8c00 alloc failed > ahc_isa_identify 9: ioport 0x9c00 alloc failed > ahc_isa_identify 10: ioport 0xac00 alloc failed > ahc_isa_identify 11: ioport 0xbc00 alloc failed > ahc_isa_identify 12: ioport 0xcc00 alloc failed > ahc_isa_identify 13: ioport 0xdc00 alloc failed > ahc_isa_identify 14: ioport 0xec00 alloc failed > 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 > pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 > pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 > pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 > pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 > pcib0: allocated type 3 (0xd4000-0xd47ff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd4800-0xd4fff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd5000-0xd57ff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd5800-0xd5fff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd6000-0xd67ff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd6800-0xd6fff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd7000-0xd77ff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd7800-0xd7fff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd8000-0xd87ff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd8800-0xd8fff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd9000-0xd97ff) for rid 3 of orm0 > pcib0: allocated type 3 (0xd9800-0xd9fff) for rid 3 of orm0 > pcib0: allocated type 3 (0xda000-0xda7ff) for rid 3 of orm0 > pcib0: allocated type 3 (0xda800-0xdafff) for rid 3 of orm0 > pcib0: allocated type 3 (0xdb000-0xdb7ff) for rid 3 of orm0 > pcib0: allocated type 3 (0xdb800-0xdbfff) for rid 3 of orm0 > isa_probe_children: disabling PnP devices > pmtimer0 on isa0 > ata: ata0 already exists; skipping it > ata: ata1 already exists; skipping it > atkbdc: atkbdc0 already exists; skipping it > atrtc: atrtc0 already exists; skipping it > attimer: attimer0 already exists; skipping it > sc: sc0 already exists; skipping it > uart: uart0 already exists; skipping it > isa_probe_children: probing non-PnP devices > orm0: at iomem > 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff,0xe000 > 0-0xeffff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 > pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 > pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 > pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 > fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > ppc0: parallel port not found. > ppc0 failed to probe at irq 7 on isa0 > uart1 failed to probe at port 0x2f8 irq 3 on isa0 > wbwd0 failed to probe on isa0 > isa_probe_children: probing PnP devices > acpi_perf0: on cpu0 > p4tcc0: on cpu0 > Device configuration finished. > procfs registered > Timecounters tick every 1.000 msec > vlan: initialized, using hash tables with chaining > tcp_init: net.inet.tcp.tcbhashsize auto tuned to 8192 > lo0: bpf attached > hpt27xx: no controller detected. > hptrr: no controller detected. > hptnr: no controller detected. > pcm0: measured ac97 link rate at 48003 Hz, will use 48000 Hz > random: unblocking device. > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > ata0: reset tp1 mask=03 ostat0=50 ostat1=00 > ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 > ata0: reset tp2 stat0=50 stat1=00 devices=0x1 > ugen2.1: at usbus2 > uhub0: on > usbus2 > ugen1.1: at usbus1 > uhub1: on > usbus1 > ugen0.1: at usbus0 > uhub2: on > usbus0 > ata1: reset tp1 mask=03 ostat0=50 ostat1=00 > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=00 stat1=00 devices=0x30000 > battery0: battery initialization start > acpi_acad0: acline initialization start > battery0: battery initialization done, tried 1 times > acpi_acad0: On Line > acpi_acad0: acline initialization done, tried 1 times > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > ata1: reset tp1 mask=03 ostat0=50 ostat1=00 > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=00 stat1=00 devices=0x30000 > (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 > 00 00 00 > (aprobe0:ata1:0:1:0): CAM status: Command timeout > (aprobe0:ata1:0:1:0): Error 5, Retry was blocked > run_interrupt_driven_hooks: still waiting after 60 seconds for > xpt_config > ata1: reset tp1 mask=03 ostat0=50 ostat1=00 > ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=00 stat1=00 devices=0x30000 > (aprobe0:ata1:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 > 00 00 00 > (aprobe0:ata1:0:1:0): CAM status: Command timeout > (aprobe0:ata1:0:1:0): Error 5, Retry was blocked > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-6 device > ada0: Serial Number MPC412Y4G6J1AE > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > GEOM: new disk ada0 > ada0: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad0 > pass0 at ata0 bus 0 scbus0 target 0 lun 0 > pass0: ATA-6 device > pass0: Serial Number MPC412Y4G6J1AE > pass0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > pass1 at ata1 bus 0 scbus1 target 0 lun 0 > pass1: Removable CD-ROM SCSI-0 > device > pass1: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0 at ata1 bus 0 scbus1 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) > cd0: cd present [288727 x 2048 byte records] > TSC timecounter disabled: C3 enabled. > Timecounter "TSC" frequency 1698592154 Hz quality -1000 > GEOM: new disk cd0 > Trying to mount root from ufs:/dev/ada0p2 [rw]... > start_init: trying /sbin/init > > > - fini - > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 22:40:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B349416 for ; Sat, 4 Oct 2014 22:40:15 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0978EA6 for ; Sat, 4 Oct 2014 22:40:14 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id lf10so3297012pab.30 for ; Sat, 04 Oct 2014 15:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=3tkypqrtYc+JHIDkByMr4zllU6OKNuM5sBFT0l2iWBc=; b=s+9y+uYT48kCMHLU7cX9eVvx0Pij/Wk0Aujy5mvPznCcNLOXgzZPr0L0r7oxduR+Yq 9IAdqi3nlVs76eliM0AA8D+CmOJB47x7dnNIvsYEdpyd7uEKz93CV9UP34LD7Ecg4F83 hEz6u6fZf++g6RuzFWWPXnJilOOsk1k4Rm0YvGS0DtOUYn+/pSeNrq6BEvYZ7d2dNihi Y2NmhsmSVCB0papJ1p8Wg73rA82/RCQ3OTWaQuajuFcCegVq2PLtbTCaqjzFhQ/HU8qi nz0jDZlxyoZEGh8s4U/1x4/DwtHF5a/Pbpk0hD2HUeKJYyhpkcTtGpT+QAuQQtQ0thVF 0T9A== X-Received: by 10.70.21.33 with SMTP id s1mr8981782pde.99.1412462414529; Sat, 04 Oct 2014 15:40:14 -0700 (PDT) Received: from charmander.picturesperfect.net (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by mx.google.com with ESMTPSA id pn1sm7357620pdb.65.2014.10.04.15.40.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Oct 2014 15:40:13 -0700 (PDT) Sender: Mark Johnston Date: Sat, 4 Oct 2014 15:40:07 -0700 From: Mark Johnston To: Ryan Stone Subject: Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3] Message-ID: <20141004224007.GA82800@charmander.picturesperfect.net> References: <20141004194756.5c291180.ohartman@zedat.fu-berlin.de> <20141004183337.GA22999@charmander.picturesperfect.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD CURRENT , "O. Hartmann" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 22:40:15 -0000 On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote: > On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston wrote: > > On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote: > >> Recent sources (Revision: 272529) fail to compile: > >> > >> [...] > >> cc -m32 -march=native -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ > >> -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -O3 -O3 > >> -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 -fstack-protector > >> -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int > >> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value > >> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch > >> -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments > >> -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc --- --- > >> libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping > >> incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for > > > > I'm confused by this message. Are you building with -DNO_CLEAN? Do you > > have anything in make.conf or src.conf, especially anything that's > > changed since libctf was rebuilt? > > > > You might try rebuilding libctf with > > > > $ cd /usr/src > > $ make -C cddl/lib/libctf clean all > > > > but I'm not sure why ld is ignoring the existing libctf.so. > > The failure is coming while building the lib32 compat libraries. Are > we not currently building a lib32 libctf.so? No, we do. One thing I've noticed is that cddl/lib is built after lib/ when compiling 32-bit libs, whereas cddl/lib is built first when building natively. But that doesn't cause any problems for me. I also don't see why ld would be searching /usr/obj/usr/src/tmp for a 32-bit lib. From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 22:58:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BCD4AC2 for ; Sat, 4 Oct 2014 22:58:50 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7B36132 for ; Sat, 4 Oct 2014 22:58:49 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so3945657wgh.35 for ; Sat, 04 Oct 2014 15:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3+tMKE+J5Tao7h5zuz97XdRe8xrdKDZfxwHRIE3kfFU=; b=FGEcvjUeeK39iPkPSsFUplAJCs/ONf4HZ4N8i5s6icTmsNSGUiLkicVJ0guq0eYRg8 0vmCVkr1EfvAHsErXNIBybDaGppUSHPaM+RI7dQRGi9atTN73/z4nTouH7ZCznGQBX13 V+LhM0OHtS3ASSlPQ06/tT77nAuFOsLpo0hLCRuZE17I41WRS70fpukM4VE94u9andMY 6s+2HfzBMNb7oN5xdH7aZFkWCpSbcZ/g6Jk8EeHfdyqNJswlHxBvMQ1/NYDPObj90mwv QzWb4g8p3iQT7o1I7RhjvdSnEgYNLuNuP4YeS4dTJMudyBjuxAt6u+2v2Ry3fqLqIUJU ieww== MIME-Version: 1.0 X-Received: by 10.180.106.104 with SMTP id gt8mr57847wib.13.1412463528112; Sat, 04 Oct 2014 15:58:48 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.194.19.38 with HTTP; Sat, 4 Oct 2014 15:58:48 -0700 (PDT) In-Reply-To: <20141004224007.GA82800@charmander.picturesperfect.net> References: <20141004194756.5c291180.ohartman@zedat.fu-berlin.de> <20141004183337.GA22999@charmander.picturesperfect.net> <20141004224007.GA82800@charmander.picturesperfect.net> Date: Sat, 4 Oct 2014 15:58:48 -0700 X-Google-Sender-Auth: nNinJzPDkbu4jdw1MOydO33AXXU Message-ID: Subject: Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3] From: Mark Johnston To: Ryan Stone , "O. Hartmann" Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 22:58:50 -0000 On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston wrote: > On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote: >> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston wrote: >> > On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote: >> >> Recent sources (Revision: 272529) fail to compile: >> >> >> >> [...] >> >> cc -m32 -march=native -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ >> >> -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -O3 -O3 >> >> -pipe -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 -fstack-protector >> >> -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int >> >> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value >> >> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch >> >> -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments >> >> -c /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- all_subdir_libproc --- --- >> >> libproc.so.3 --- /usr/obj/usr/src/tmp/usr/bin/ld: skipping >> >> incompatible /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for >> > >> > I'm confused by this message. Are you building with -DNO_CLEAN? Do you >> > have anything in make.conf or src.conf, especially anything that's >> > changed since libctf was rebuilt? >> > >> > You might try rebuilding libctf with >> > >> > $ cd /usr/src >> > $ make -C cddl/lib/libctf clean all >> > >> > but I'm not sure why ld is ignoring the existing libctf.so. >> >> The failure is coming while building the lib32 compat libraries. Are >> we not currently building a lib32 libctf.so? > > No, we do. One thing I've noticed is that cddl/lib is built after lib/ > when compiling 32-bit libs, whereas cddl/lib is built first when building > natively. Sorry, that's not even true. I misread a part of Makefile.inc1. I'm still not able to reproduce the problem, but it seems that the patch here is appropriate: http://people.freebsd.org/~markj/patches/libctf_prebuild.diff Oliver, could you give this a try? From owner-freebsd-current@FreeBSD.ORG Sat Oct 4 23:41:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E622F80E for ; Sat, 4 Oct 2014 23:41:18 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4E66182 for ; Sat, 4 Oct 2014 23:41:18 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id 864A41604D0; Sat, 4 Oct 2014 16:41:11 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 071FF1603BC for ; Sat, 4 Oct 2014 16:41:08 -0700 (MST) Message-ID: <54308593.6050301@pinyon.org> Date: Sat, 04 Oct 2014 16:41:07 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: CURRENT: buildworld fails to compile: cannot find -lctf cc: error: linker command failed [libproc.so.3] References: <20141004194756.5c291180.ohartman@zedat.fu-berlin.de> <20141004183337.GA22999@charmander.picturesperfect.net> <20141004224007.GA82800@charmander.picturesperfect.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 23:41:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/04/14 15:58, Mark Johnston wrote: > On Sat, Oct 4, 2014 at 3:40 PM, Mark Johnston > wrote: >> On Sat, Oct 04, 2014 at 04:39:37PM -0400, Ryan Stone wrote: >>> On Sat, Oct 4, 2014 at 2:33 PM, Mark Johnston >>> wrote: >>>> On Sat, Oct 04, 2014 at 07:47:56PM +0200, O. Hartmann wrote: >>>>> Recent sources (Revision: 272529) fail to compile: >>>>> >>>>> [...] cc -m32 -march=native -DCOMPAT_32BIT -isystem >>>>> /usr/obj/usr/src/lib32/usr/include/ >>>>> -L/usr/obj/usr/src/lib32/usr/lib32 >>>>> -B/usr/obj/usr/src/lib32/usr/lib32 -O2 -pipe -O3 -O3 -pipe >>>>> -DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 >>>>> -fstack-protector -Wsystem-headers -Werror >>>>> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int >>>>> -Wno-unused-const-variable -Wno-tautological-compare >>>>> -Wno-unused-value -Wno-parentheses-equality >>>>> -Wno-unused-function -Wno-enum-conversion -Wno-switch >>>>> -Wno-switch-enum -Wno-knr-promoted-parameter >>>>> -Wno-parentheses -Qunused-arguments -c >>>>> /usr/src/lib/librpcsvc/yp_passwd.c -o yp_passwd.o --- >>>>> all_subdir_libproc --- --- libproc.so.3 --- >>>>> /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible >>>>> /usr/obj/usr/src/tmp/usr/lib/libctf.so when searching for >>>> >>>> I'm confused by this message. Are you building with >>>> -DNO_CLEAN? Do you have anything in make.conf or src.conf, >>>> especially anything that's changed since libctf was rebuilt? >>>> >>>> You might try rebuilding libctf with >>>> >>>> $ cd /usr/src $ make -C cddl/lib/libctf clean all >>>> >>>> but I'm not sure why ld is ignoring the existing libctf.so. >>> >>> The failure is coming while building the lib32 compat >>> libraries. Are we not currently building a lib32 libctf.so? >> >> No, we do. One thing I've noticed is that cddl/lib is built after >> lib/ when compiling 32-bit libs, whereas cddl/lib is built first >> when building natively. > > Sorry, that's not even true. I misread a part of Makefile.inc1. > > I'm still not able to reproduce the problem, but it seems that the > patch here is appropriate: > http://people.freebsd.org/~markj/patches/libctf_prebuild.diff > > Oliver, could you give this a try? Even poudriere can't get past this one. Russell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUMIWTAAoJEFnLrGVSDFaEPNkP/i0eo+rmHzyT9qH7F+iJOn8r 2WbN7OKT8Q086nI/rtHAqEeOiIUkXPhxfQiU2zrjXt551zgrAsfdqe39P6kLm1ha L3yA3joVkjLdWwpDMKEUtm9EChVG//rM258xWKhSTnGBnw4Qvtzy458SdAIXap3J HjTMJfZ95QuWanoK0HIN0glVoXdO/gVjmifm4CMmRKpKESjsU3vvCckbqDBim0Vi kmSWhL+dHucaX4b/8hQ/Csn6AKIZoo6LNw8cphZGS9dAvf+0f4PKCZ2KJhwV61TE rCi5AstFYoWgCk3LKAxMR4bquvtNusTvT5YokDQ4qMwwpihNR8PL6C5IP3bo/RkI tp4x959Yq5b7RVmmU7IDTQlWA5WoiQMYDGj/HC4iMkfBHzf7Cxl4sl4/HZwJ3fXu TkCm/EKKyah3heS/wF4tKx4npjBLu6+rWJLFdhCTLS2PWmdMNzBUB65vFrvdTEZl EFWpiITuV0Dd3Kb46s/Jm/26X1UMZRnKDJEMGtEauJj7hfwoR35+ym/WxI0PnMsz b4x+NxdPWQbOlRX3pnumcGVI1fuaRMJ8Dbdof7r/CXQITzZjHgbXVvZ0nnAh67L3 Om1G8be2w0jXfTPDI7qQxHIQfoua95VYMdvOcq48mnq3kDSuU+y3BUXamnqsrWqT K3N72p7T3F/8TsmiFzAI =IbPc -----END PGP SIGNATURE-----