From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 07:02:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1D651F65 for ; Mon, 7 Oct 2013 07:02:39 +0000 (UTC) (envelope-from syuu@dokukino.com) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E12D628C9 for ; Mon, 7 Oct 2013 07:02:38 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kp14so6860202pab.6 for ; Mon, 07 Oct 2013 00:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dokukino.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ve9X9By3o5ZBkRDMqhQpD+fd7vv52QRdIhKsinGPfYM=; b=V0xmCYsj+Tw0+mYDDV3rSoye+ZPsxRTyAqLWLrdyaE8FExIpyCXCU6lXSCRihfPpJB Rbo9/xMIbiaxNoaoWRn8QXn3+ccKLdmxhi9lkgHWbcw7K5C/UTanCkx2b0tDFhfuJyV+ WdpVI+1/ru5ONcv4QbA9qBDWso+LYYNc0S+74= 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:from:date :message-id:subject:to:content-type; bh=ve9X9By3o5ZBkRDMqhQpD+fd7vv52QRdIhKsinGPfYM=; b=OC3kwhNivRu5RZIHeCzmc5bhak1g83d53XpwAusDJfDZFLfvF2+GgA/voNDNgsxRVq +0v6G8AafVp4Aj1HHq1No8MQHMxweELNerfF/q1G2OQJWkxQT4SmgYmorl32rn+Rfmhs EaanPCMmz4mdodJU34olktoQgNUSh8HUmFz2J66IjBjakNLLa19e96BEeHY9zpeCG66l 9N7nChV3IpdIc0k69kTo5Wi4O8G9cE6WFq1NXbRiAcLICpi4RTjrF3uNjXHPxuAGGqNF +aztGvxr/puahr/aABsM5/4K2GhEchMBFvLGFdwxVGVdKYAICd5X5nBGAV1Utz1cUlT2 gE8g== X-Gm-Message-State: ALoCoQnb/21/QxjZ4tQyqPc0vAzzvPG1KCm8lxCGf6xRvAk5AV9eC3t+ZJRJ0mF/oHgm6R6rR2yO X-Received: by 10.66.102.66 with SMTP id fm2mr30281663pab.94.1381129358458; Mon, 07 Oct 2013 00:02:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.138 with HTTP; Mon, 7 Oct 2013 00:01:58 -0700 (PDT) In-Reply-To: References: From: Takuya ASADA Date: Mon, 7 Oct 2013 16:01:58 +0900 Message-ID: Subject: Re: Adding Flow Director sysctls to ixgbe(4) (was: netmap: traffic distribution) To: "freebsd-net@freebsd.org" Content-Type: multipart/mixed; boundary=047d7bd90edecde4f304e8213c67 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 07:02:39 -0000 --047d7bd90edecde4f304e8213c67 Content-Type: text/plain; charset=UTF-8 Hi, This is updated version of "ixgbetool" patch. Here's improved feature list: - signature filter list feature available - user-defined filter can be use with an ATR. To enable it, add "hw.ixgbe.cooperative_atr=1" on /boot/loader.conf Usage is as follows: ixgbetool [operation] add_sig_filter show_sig_filter del_sig_filter 2013/9/30 Takuya ASADA > Hi, > > I just implemented device specific ioctl with device specific > configuration tool. > It still doesn't support some important features such as: > - FDIR enable / disable via sysctl or tunable params > - ATR enable / disable via sysctl or tunable params > - IPv6 support on signature filter > - signature filter list > - support perfect filter > But, at least it can configure signature filter manually. > > Usage is as follows: > Usage: ixgbetool [operation] > add_sig_filter > del_sig_filter > > > 2013/9/28 hiren panchasara > >> >> >> >> On Fri, Sep 27, 2013 at 1:58 AM, Takuya ASADA wrote: >> >>> 2013/9/27 Adrian Chadd >>> >>>> On 27 September 2013 00:43, hiren panchasara < >>>> hiren.panchasara@gmail.com> wrote: >>>> >>>> >>>>> Takuya, >>>>> >>>>> I see a lot of responses/comments on proposed changes. Was anything >>>>> decided >>>>> at the end of it? As far as I can tell, its still not committed to the >>>>> tree. >>>>> >>>> >>>> I'd rather see an ioctl API for that chipset and then have a separate >>>> tool program it for now. >>>> >>> >>> Ah, like cxgbetool and cxgbe? (it has device specific tool and ioctls) >>> http://svnweb.freebsd.org/base/head/tools/tools/cxgbetool/ >>> >> >> Something like this for ixgbe would be nice to start with, imo. >> >> Cheers, >> Hiren >> >>> http://svnweb.freebsd.org/base/head/sys/dev/cxgb/ >>> >>> >>>> So, how bout we hack that up? :) >>>> >>> >>> Sound's interesting ;-) >>> Could you tell me more detail about your idea? >>> >>> >> > --047d7bd90edecde4f304e8213c67 Content-Type: application/octet-stream; name="ixgbetool-v004.diff" Content-Disposition: attachment; filename="ixgbetool-v004.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hmhcjir91 ZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzIGIvc3lzL2NvbmYvZmlsZXMKaW5kZXggYTM3MGNm YS4uOWU1YWRhNyAxMDA2NDQKLS0tIGEvc3lzL2NvbmYvZmlsZXMKKysrIGIvc3lzL2NvbmYvZmls ZXMKQEAgLTE3MzQsNiArMTczNCw4IEBAIGRldi9peGdiZS9peGdiZV9kY2JfODI1OTguYwlvcHRp b25hbCBpeGdiZSBpbmV0IFwKIAljb21waWxlLXdpdGggIiR7Tk9STUFMX0N9IC1JJFMvZGV2L2l4 Z2JlIgogZGV2L2l4Z2JlL2l4Z2JlX2RjYl84MjU5OS5jCW9wdGlvbmFsIGl4Z2JlIGluZXQgXAog CWNvbXBpbGUtd2l0aCAiJHtOT1JNQUxfQ30gLUkkUy9kZXYvaXhnYmUiCitkZXYvaXhnYmUvaXhn YmVfdWZpbHRlci5jCW9wdGlvbmFsIGl4Z2JlIGluZXQgXAorCWNvbXBpbGUtd2l0aCAiJHtOT1JN QUxfQ30gLUkkUy9kZXYvaXhnYmUgLURTTVAgLURJWEdCRV9GRElSIgogZGV2L2ptZS9pZl9qbWUu YwkJb3B0aW9uYWwgam1lIHBjaQogZGV2L2pveS9qb3kuYwkJCW9wdGlvbmFsIGpveQogZGV2L2pv eS9qb3lfaXNhLmMJCW9wdGlvbmFsIGpveSBpc2EKZGlmZiAtLWdpdCBhL3N5cy9kZXYvaXhnYmUv aXhnYmUuYyBiL3N5cy9kZXYvaXhnYmUvaXhnYmUuYwppbmRleCBiNjVkZjcyLi40MGQ5NDhiIDEw MDY0NAotLS0gYS9zeXMvZGV2L2l4Z2JlL2l4Z2JlLmMKKysrIGIvc3lzL2Rldi9peGdiZS9peGdi ZS5jCkBAIC0zMjYsNyArMzI2LDggQEAgc3RhdGljIGludCBpeGdiZV90b3RhbF9wb3J0czsKICoq IFRoaXMgZmVhdHVyZSBjYW4gYmUgZGlzYWJsZWQgYnkgCiAqKiBzZXR0aW5nIHRoaXMgdG8gMC4K ICovCi1zdGF0aWMgaW50IGF0cl9zYW1wbGVfcmF0ZSA9IDIwOworaW50IGl4Z2JlX2F0cl9zYW1w bGVfcmF0ZSA9IDIwOworVFVOQUJMRV9JTlQoImh3Lml4Z2JlLmF0cl9zYW1wbGVfcmF0ZSIsICZp eGdiZV9hdHJfc2FtcGxlX3JhdGUpOwogLyogCiAqKiBGbG93IERpcmVjdG9yIGFjdHVhbGx5ICdz dGVhbHMnCiAqKiBwYXJ0IG9mIHRoZSBwYWNrZXQgYnVmZmVyIGFzIGl0cwpAQCAtNDQyLDYgKzQ0 MywxMyBAQCBpeGdiZV9hdHRhY2goZGV2aWNlX3QgZGV2KQogCQkJT0lEX0FVVE8sICJlbmFibGVf YWltIiwgQ1RMVFlQRV9JTlR8Q1RMRkxBR19SVywKIAkJCSZpeGdiZV9lbmFibGVfYWltLCAxLCAi SW50ZXJydXB0IE1vZGVyYXRpb24iKTsKIAorI2lmZGVmIElYR0JFX0ZESVIKKyAgICAgICAgU1lT Q1RMX0FERF9JTlQoZGV2aWNlX2dldF9zeXNjdGxfY3R4KGRldiksCisJCQlTWVNDVExfQ0hJTERS RU4oZGV2aWNlX2dldF9zeXNjdGxfdHJlZShkZXYpKSwKKwkJCU9JRF9BVVRPLCAiYXRyX3NhbXBs ZV9yYXRlIiwgQ1RMVFlQRV9JTlR8Q1RMRkxBR19SRCwKKwkJCSZpeGdiZV9hdHJfc2FtcGxlX3Jh dGUsIDIwLCAiQVRSIHNhbXBsZSByYXRlIik7CisjZW5kaWYKKwogCS8qCiAJKiogQWxsb3cgYSBr aW5kIG9mIHNwZWVkIGNvbnRyb2wgYnkgZm9yY2luZyB0aGUgYXV0b25lZwogCSoqIGFkdmVydGlz ZWQgc3BlZWQgbGlzdCB0byBvbmx5IGEgY2VydGFpbiB2YWx1ZSwgdGhpcwpAQCAtNjA0LDYgKzYx MiwxMyBAQCBpeGdiZV9hdHRhY2goZGV2aWNlX3QgZGV2KQogI2lmZGVmIERFVl9ORVRNQVAKIAlp eGdiZV9uZXRtYXBfYXR0YWNoKGFkYXB0ZXIpOwogI2VuZGlmIC8qIERFVl9ORVRNQVAgKi8KKwor I2lmZGVmIElYR0JFX0ZESVIKKwllcnJvciA9IGl4Z2JlX3VmaWx0ZXJfYXR0YWNoKGFkYXB0ZXIp OworCWlmIChlcnJvcikKKwkJZ290byBlcnJfbGF0ZTsKKyNlbmRpZgorCiAJSU5JVF9ERUJVR09V VCgiaXhnYmVfYXR0YWNoOiBlbmQiKTsKIAlyZXR1cm4gKDApOwogZXJyX2xhdGU6CkBAIC02OTMs NiArNzA4LDEwIEBAIGl4Z2JlX2RldGFjaChkZXZpY2VfdCBkZXYpCiAJaXhnYmVfZnJlZV9yZWNl aXZlX3N0cnVjdHVyZXMoYWRhcHRlcik7CiAJZnJlZShhZGFwdGVyLT5tdGEsIE1fREVWQlVGKTsK IAorI2lmZGVmIElYR0JFX0ZESVIKKwlpeGdiZV91ZmlsdGVyX2RldGFjaChhZGFwdGVyKTsKKyNl bmRpZgorCiAJSVhHQkVfQ09SRV9MT0NLX0RFU1RST1koYWRhcHRlcik7CiAJcmV0dXJuICgwKTsK IH0KQEAgLTE4MTYsNyArMTgzNSw3IEBAIHJldHJ5OgogCS8qIERvIHRoZSBmbG93IGRpcmVjdG9y IG1hZ2ljICovCiAJaWYgKCh0eHItPmF0cl9zYW1wbGUpICYmICghYWRhcHRlci0+ZmRpcl9yZWlu aXQpKSB7CiAJCSsrdHhyLT5hdHJfY291bnQ7Ci0JCWlmICh0eHItPmF0cl9jb3VudCA+PSBhdHJf c2FtcGxlX3JhdGUpIHsKKwkJaWYgKHR4ci0+YXRyX2NvdW50ID49IGl4Z2JlX2F0cl9zYW1wbGVf cmF0ZSkgewogCQkJaXhnYmVfYXRyKHR4ciwgbV9oZWFkKTsKIAkJCXR4ci0+YXRyX2NvdW50ID0g MDsKIAkJfQpAQCAtMzA2Miw3ICszMDgxLDcgQEAgaXhnYmVfc2V0dXBfdHJhbnNtaXRfcmluZyhz dHJ1Y3QgdHhfcmluZyAqdHhyKQogI2lmZGVmIElYR0JFX0ZESVIKIAkvKiBTZXQgdGhlIHJhdGUg YXQgd2hpY2ggd2Ugc2FtcGxlIHBhY2tldHMgKi8KIAlpZiAoYWRhcHRlci0+aHcubWFjLnR5cGUg IT0gaXhnYmVfbWFjXzgyNTk4RUIpCi0JCXR4ci0+YXRyX3NhbXBsZSA9IGF0cl9zYW1wbGVfcmF0 ZTsKKwkJdHhyLT5hdHJfc2FtcGxlID0gaXhnYmVfYXRyX3NhbXBsZV9yYXRlOwogI2VuZGlmCiAK IAkvKiBTZXQgbnVtYmVyIG9mIGRlc2NyaXB0b3JzIGF2YWlsYWJsZSAqLwpAQCAtMzU0Niw2ICsz NTY1LDEzIEBAIGl4Z2JlX2F0cihzdHJ1Y3QgdHhfcmluZyAqdHhyLCBzdHJ1Y3QgbWJ1ZiAqbXAp CiAJY29tbW9uLmlwIF49IGlwLT5pcF9zcmMuc19hZGRyIF4gaXAtPmlwX2RzdC5zX2FkZHI7CiAK IAlxdWUgPSAmYWRhcHRlci0+cXVldWVzW3R4ci0+bWVdOworCisJaWYgKGl4Z2JlX2Nvb3BlcmF0 aXZlX2F0cikgeworCQl1MzIgaGFzaDsKKwkJaGFzaCA9IGl4Z2JlX2F0cl9jb21wdXRlX3NpZ19o YXNoXzgyNTk5KGlucHV0LCBjb21tb24pOworCQlpZiAoaXhnYmVfdWZpbHRlcl9leGlzdHMoYWRh cHRlciwgaGFzaCkpCisJCQlyZXR1cm47CisJfQogCS8qCiAJKiogVGhpcyBhc3N1bWVzIHRoZSBS eCBxdWV1ZSBhbmQgVHgKIAkqKiBxdWV1ZSBhcmUgYm91bmQgdG8gdGhlIHNhbWUgQ1BVCmRpZmYg LS1naXQgYS9zeXMvZGV2L2l4Z2JlL2l4Z2JlLmggYi9zeXMvZGV2L2l4Z2JlL2l4Z2JlLmgKaW5k ZXggNzdiNzJlZC4uMGJhMDUyMyAxMDA2NDQKLS0tIGEvc3lzL2Rldi9peGdiZS9peGdiZS5oCisr KyBiL3N5cy9kZXYvaXhnYmUvaXhnYmUuaApAQCAtOTAsNiArOTAsNyBAQAogI2luY2x1ZGUgPG1h Y2hpbmUvc21wLmg+CiAKICNpbmNsdWRlICJpeGdiZV9hcGkuaCIKKyNpbmNsdWRlICJpeGdiZV91 ZmlsdGVyLmgiCiAKIC8qIFR1bmFibGVzICovCiAKQEAgLTQ2OCw4ICs0NjksMTEgQEAgc3RydWN0 IGFkYXB0ZXIgewogCXVuc2lnbmVkIGxvbmcJCWxpbmtfaXJxOwogCiAJc3RydWN0IGl4Z2JlX2h3 X3N0YXRzIAlzdGF0czsKLX07CiAKKyNpZmRlZiBJWEdCRV9GRElSCisJc3RydWN0IGl4Z2JlX3Vm aWx0ZXIJdWZpbHRlcjsKKyNlbmRpZgorfTsKIAogLyogUHJlY2lzaW9uIFRpbWUgU3luYyAoSUVF RSAxNTg4KSBkZWZpbmVzICovCiAjZGVmaW5lIEVUSEVSVFlQRV9JRUVFMTU4OCAgICAgIDB4ODhG NwpAQCAtNTQwLDQgKzU0NCw4IEBAIGl4Z2JlX3J4X3VucmVmcmVzaGVkKHN0cnVjdCByeF9yaW5n ICpyeHIpCiAJCSAgICByeHItPm5leHRfdG9fcmVmcmVzaCAtIDEpOwogfSAgICAgICAKIAorI2lm ZGVmIElYR0JFX0ZESVIKK2V4dGVybiBpbnQgaXhnYmVfYXRyX3NhbXBsZV9yYXRlOworI2VuZGlm CisKICNlbmRpZiAvKiBfSVhHQkVfSF8gKi8KZGlmZiAtLWdpdCBhL3N5cy9kZXYvaXhnYmUvaXhn YmVfODI1OTkuYyBiL3N5cy9kZXYvaXhnYmUvaXhnYmVfODI1OTkuYwppbmRleCAzY2M4Y2Q3Li43 NGQzYWU5IDEwMDY0NAotLS0gYS9zeXMvZGV2L2l4Z2JlL2l4Z2JlXzgyNTk5LmMKKysrIGIvc3lz L2Rldi9peGdiZS9peGdiZV84MjU5OS5jCkBAIC0xNjY3LDYgKzE2NjcsNTUgQEAgczMyIGl4Z2Jl X2ZkaXJfYWRkX3NpZ25hdHVyZV9maWx0ZXJfODI1OTkoc3RydWN0IGl4Z2JlX2h3ICpodywKIAly ZXR1cm4gSVhHQkVfU1VDQ0VTUzsKIH0KIAorLyoqCisgKiAgaXhnYmVfZmRpcl9lcmFzZV9zaWdu YXR1cmVfZmlsdGVyXzgyNTk5IC0gRXJhc2UgYSBzaWduYXR1cmUgaGFzaCBmaWx0ZXIKKyAqICBA aHc6IHBvaW50ZXIgdG8gaGFyZHdhcmUgc3RydWN0dXJlCisgKiAgQHN0cmVhbTogaW5wdXQgYml0 c3RyZWFtCisgKiovCitzMzIgaXhnYmVfZmRpcl9lcmFzZV9zaWduYXR1cmVfZmlsdGVyXzgyNTk5 KHN0cnVjdCBpeGdiZV9odyAqaHcsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB1bmlvbiBpeGdiZV9hdHJfaGFzaF9kd29yZCBpbnB1dCwKKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuaW9uIGl4Z2JlX2F0cl9oYXNoX2R3b3JkIGNv bW1vbikKK3sKKwl1NjQgIGZkaXJoYXNoY21kOworCXUzMiAgZmRpcmNtZDsKKworCURFQlVHRlVO QygiaXhnYmVfZmRpcl9lcmFzZV9zaWduYXR1cmVfZmlsdGVyXzgyNTk5Iik7CisKKwkvKgorCSAq IEdldCB0aGUgZmxvd190eXBlIGluIG9yZGVyIHRvIHByb2dyYW0gRkRJUkNNRCBwcm9wZXJseQor CSAqIGxvd2VzdCAyIGJpdHMgYXJlIEZESVJDTUQuTDRUWVBFLCB0aGlyZCBsb3dlc3QgYml0IGlz IEZESVJDTUQuSVBWNgorCSAqLworCXN3aXRjaCAoaW5wdXQuZm9ybWF0dGVkLmZsb3dfdHlwZSkg eworCWNhc2UgSVhHQkVfQVRSX0ZMT1dfVFlQRV9UQ1BWNDoKKwljYXNlIElYR0JFX0FUUl9GTE9X X1RZUEVfVURQVjQ6CisJY2FzZSBJWEdCRV9BVFJfRkxPV19UWVBFX1NDVFBWNDoKKwljYXNlIElY R0JFX0FUUl9GTE9XX1RZUEVfVENQVjY6CisJY2FzZSBJWEdCRV9BVFJfRkxPV19UWVBFX1VEUFY2 OgorCWNhc2UgSVhHQkVfQVRSX0ZMT1dfVFlQRV9TQ1RQVjY6CisJCWJyZWFrOworCWRlZmF1bHQ6 CisJCURFQlVHT1VUKCIgRXJyb3Igb24gZmxvdyB0eXBlIGlucHV0XG4iKTsKKwkJcmV0dXJuIElY R0JFX0VSUl9DT05GSUc7CisJfQorCisJLyogY29uZmlndXJlIEZESVJDTUQgcmVnaXN0ZXIgKi8K KwlmZGlyY21kID0gSVhHQkVfRkRJUkNNRF9DTURfUkVNT1ZFX0ZMT1cgfCAKKwkgICAgICAgICAg SVhHQkVfRkRJUkNNRF9MQVNUIHwgSVhHQkVfRkRJUkNNRF9RVUVVRV9FTjsKKwlmZGlyY21kIHw9 IGlucHV0LmZvcm1hdHRlZC5mbG93X3R5cGUgPDwgSVhHQkVfRkRJUkNNRF9GTE9XX1RZUEVfU0hJ RlQ7CisKKwkvKgorCSAqIFRoZSBsb3dlciAzMi1iaXRzIG9mIGZkaXJoYXNoY21kIGlzIGZvciBG RElSSEFTSCwgdGhlIHVwcGVyIDMyLWJpdHMKKwkgKiBpcyBmb3IgRkRJUkNNRC4gIFRoZW4gZG8g YSA2NC1iaXQgcmVnaXN0ZXIgd3JpdGUgZnJvbSBGRElSSEFTSC4KKwkgKi8KKwlmZGlyaGFzaGNt ZCA9ICh1NjQpZmRpcmNtZCA8PCAzMjsKKwlmZGlyaGFzaGNtZCB8PSBpeGdiZV9hdHJfY29tcHV0 ZV9zaWdfaGFzaF84MjU5OShpbnB1dCwgY29tbW9uKTsKKwlJWEdCRV9XUklURV9SRUc2NChodywg SVhHQkVfRkRJUkhBU0gsIGZkaXJoYXNoY21kKTsKKworCURFQlVHT1VUMSgiVHggaGFzaD0leFxu IiwgKHUzMilmZGlyaGFzaGNtZCk7CisKKwlyZXR1cm4gSVhHQkVfU1VDQ0VTUzsKK30KKwogI2Rl ZmluZSBJWEdCRV9DT01QVVRFX0JLVF9IQVNIX0lURVJBVElPTihfbikgXAogZG8geyBcCiAJdTMy IG4gPSAoX24pOyBcCmRpZmYgLS1naXQgYS9zeXMvZGV2L2l4Z2JlL2l4Z2JlX2FwaS5oIGIvc3lz L2Rldi9peGdiZS9peGdiZV9hcGkuaAppbmRleCA5MTAyM2FlLi43N2M2NDI3IDEwMDY0NAotLS0g YS9zeXMvZGV2L2l4Z2JlL2l4Z2JlX2FwaS5oCisrKyBiL3N5cy9kZXYvaXhnYmUvaXhnYmVfYXBp LmgKQEAgLTE0NCw2ICsxNDQsOSBAQCBzMzIgaXhnYmVfZmRpcl9hZGRfc2lnbmF0dXJlX2ZpbHRl cl84MjU5OShzdHJ1Y3QgaXhnYmVfaHcgKmh3LAogCQkJCQkgIHVuaW9uIGl4Z2JlX2F0cl9oYXNo X2R3b3JkIGlucHV0LAogCQkJCQkgIHVuaW9uIGl4Z2JlX2F0cl9oYXNoX2R3b3JkIGNvbW1vbiwK IAkJCQkJICB1OCBxdWV1ZSk7CitzMzIgaXhnYmVfZmRpcl9lcmFzZV9zaWduYXR1cmVfZmlsdGVy XzgyNTk5KHN0cnVjdCBpeGdiZV9odyAqaHcsCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB1bmlvbiBpeGdiZV9hdHJfaGFzaF9kd29yZCBpbnB1dCwKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHVuaW9uIGl4Z2JlX2F0cl9oYXNoX2R3 b3JkIGNvbW1vbik7CiBzMzIgaXhnYmVfZmRpcl9zZXRfaW5wdXRfbWFza184MjU5OShzdHJ1Y3Qg aXhnYmVfaHcgKmh3LAogCQkJCSAgICB1bmlvbiBpeGdiZV9hdHJfaW5wdXQgKmlucHV0X21hc2sp OwogczMyIGl4Z2JlX2ZkaXJfd3JpdGVfcGVyZmVjdF9maWx0ZXJfODI1OTkoc3RydWN0IGl4Z2Jl X2h3ICpodywKZGlmZiAtLWdpdCBhL3N5cy9kZXYvaXhnYmUvaXhnYmVfdWZpbHRlci5jIGIvc3lz L2Rldi9peGdiZS9peGdiZV91ZmlsdGVyLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAw MDAwMC4uZTVkNDQ2MgotLS0gL2Rldi9udWxsCisrKyBiL3N5cy9kZXYvaXhnYmUvaXhnYmVfdWZp bHRlci5jCkBAIC0wLDAgKzEsMjYwIEBACisKKyNpbmNsdWRlICJpeGdiZS5oIgorI2luY2x1ZGUg PHN5cy9jb25mLmg+CisjaW5jbHVkZSA8c3lzL3ByaXYuaD4KKworI2lmZGVmIElYR0JFX0ZESVIK K3N0YXRpYyBkX29wZW5fdCBpeGdiZV91ZmlsdGVyX29wZW47CitzdGF0aWMgZF9jbG9zZV90IGl4 Z2JlX3VmaWx0ZXJfY2xvc2U7CitzdGF0aWMgZF9pb2N0bF90IGl4Z2JlX3VmaWx0ZXJfaW9jdGw7 CitzdGF0aWMgc3RydWN0IGNkZXZzdyBjZGV2c3cgPSB7CisgICAgICAgLmRfdmVyc2lvbiA9ICAg IERfVkVSU0lPTiwKKyAgICAgICAuZF9mbGFncyA9ICAgICAgMCwKKyAgICAgICAuZF9vcGVuID0g ICAgICAgaXhnYmVfdWZpbHRlcl9vcGVuLAorICAgICAgIC5kX2Nsb3NlID0gICAgICBpeGdiZV91 ZmlsdGVyX2Nsb3NlLAorICAgICAgIC5kX2lvY3RsID0gICAgICBpeGdiZV91ZmlsdGVyX2lvY3Rs LAorICAgICAgIC5kX25hbWUgPSAgICAgICAiaXgiLAorfTsKKworc3RhdGljIGludCB1ZmlsdGVy X2hhc2hfc2l6ZSA9IDY1NTM2OworVFVOQUJMRV9JTlQoImh3Lml4Z2JlLnVmaWx0ZXJfaGFzaF9z aXplIiwgJnVmaWx0ZXJfaGFzaF9zaXplKTsKK2ludCBpeGdiZV9jb29wZXJhdGl2ZV9hdHIgPSAw OworVFVOQUJMRV9JTlQoImh3Lml4Z2JlLmNvb3BlcmF0aXZlX2F0ciIsICZpeGdiZV9jb29wZXJh dGl2ZV9hdHIpOworCitzdGF0aWMgaW5saW5lIHZvaWQKK2xpc3RfaW5zZXJ0KHN0cnVjdCBpeGdi ZV91ZmlsdGVyICp1ZmlsdGVyLCBzdHJ1Y3QgdWZpbHRlcl9rZW50cnkgKmtlKQoreworCVRBSUxR X0lOU0VSVF9UQUlMKCZ1ZmlsdGVyLT5saXN0LCBrZSwgdHFfbGluayk7Cit9CisKK3N0YXRpYyBp bmxpbmUgdm9pZAorbGlzdF9yZW1vdmUoc3RydWN0IGl4Z2JlX3VmaWx0ZXIgKnVmaWx0ZXIsIHN0 cnVjdCB1ZmlsdGVyX2tlbnRyeSAqa2UpCit7CisJVEFJTFFfUkVNT1ZFKCZ1ZmlsdGVyLT5saXN0 LCBrZSwgdHFfbGluayk7Cit9CisKK3N0YXRpYyBpbmxpbmUgc3RydWN0IHVmaWx0ZXJfa2VudHJ5 ICoKK2xpc3RfZmluZChzdHJ1Y3QgaXhnYmVfdWZpbHRlciAqdWZpbHRlciwgdW5zaWduZWQgaWQp Cit7CisJc3RydWN0IHVmaWx0ZXJfa2VudHJ5ICprZTsKKworCVRBSUxRX0ZPUkVBQ0goa2UsICZ1 ZmlsdGVyLT5saXN0LCB0cV9saW5rKQorCQlpZiAoa2UtPmUuaWQgPT0gaWQpCisJCQlyZXR1cm4g KGtlKTsKKwlyZXR1cm4gKE5VTEwpOworfQorCitzdGF0aWMgaW5saW5lIHZvaWQKK2xpc3RfZnJl ZWFsbChzdHJ1Y3QgaXhnYmVfdWZpbHRlciAqdWZpbHRlcikKK3sKKwlzdHJ1Y3QgdWZpbHRlcl9r ZW50cnkgKmtlLCAqdDsKKworCVRBSUxRX0ZPUkVBQ0hfU0FGRShrZSwgJnVmaWx0ZXItPmxpc3Qs IHRxX2xpbmssIHQpCisJCWZyZWUoa2UsIE1fREVWQlVGKTsKK30KKworc3RhdGljIGlubGluZSB2 b2lkCitoYXNoX2luc2VydChzdHJ1Y3QgaXhnYmVfdWZpbHRlciAqdWZpbHRlciwgc3RydWN0IHVm aWx0ZXJfa2VudHJ5ICprZSkKK3sKKwlpbnQgYnVja2V0OworCQorCWJ1Y2tldCA9IGtlLT5oYXNo ICYgdWZpbHRlci0+aGFzaG1hc2s7CisJcm1fd2xvY2soJnVmaWx0ZXItPmhhc2hsb2NrKTsKKwlM SVNUX0lOU0VSVF9IRUFEKCZ1ZmlsdGVyLT5oYXNoW2J1Y2tldF0sIGtlLCBsaV9saW5rKTsKKwly bV93dW5sb2NrKCZ1ZmlsdGVyLT5oYXNobG9jayk7Cit9CisKK3N0YXRpYyBpbmxpbmUgdm9pZAor aGFzaF9yZW1vdmUoc3RydWN0IGl4Z2JlX3VmaWx0ZXIgKnVmaWx0ZXIsIHN0cnVjdCB1ZmlsdGVy X2tlbnRyeSAqa2UpCit7CisJaW50IGJ1Y2tldDsKKworCWJ1Y2tldCA9IGtlLT5oYXNoICYgdWZp bHRlci0+aGFzaG1hc2s7CisJcm1fd2xvY2soJnVmaWx0ZXItPmhhc2hsb2NrKTsKKwlMSVNUX1JF TU9WRShrZSwgbGlfbGluayk7CisJZnJlZShrZSwgTV9ERVZCVUYpOworCXJtX3d1bmxvY2soJnVm aWx0ZXItPmhhc2hsb2NrKTsKK30KKworaW50CitpeGdiZV91ZmlsdGVyX2V4aXN0cyhzdHJ1Y3Qg YWRhcHRlciAqYWRhcHRlciwgdTMyIGhhc2gpCit7CisJc3RydWN0IGl4Z2JlX3VmaWx0ZXIgKnVm aWx0ZXIgPSAmYWRhcHRlci0+dWZpbHRlcjsKKwlpbnQgYnVja2V0OworCXN0cnVjdCBybV9wcmlv dHJhY2tlciB0cmFja2VyOworCXN0cnVjdCB1ZmlsdGVyX2tlbnRyeSAqa2U7CisJaW50IGZvdW5k ID0gMDsKKworCWJ1Y2tldCA9IGhhc2ggJiB1ZmlsdGVyLT5oYXNobWFzazsKKwlybV9ybG9jaygm dWZpbHRlci0+aGFzaGxvY2ssICZ0cmFja2VyKTsKKwlMSVNUX0ZPUkVBQ0goa2UsICZ1ZmlsdGVy LT5oYXNoW2J1Y2tldF0sIGxpX2xpbmspIHsKKwkJaWYgKGtlLT5oYXNoID09IGhhc2gpIHsKKwkJ CWZvdW5kKys7CisJCQlicmVhazsKKwkJfQorCX0KKwlybV9ydW5sb2NrKCZ1ZmlsdGVyLT5oYXNo bG9jaywgJnRyYWNrZXIpOworCisJcmV0dXJuIChmb3VuZCk7Cit9CisKK2ludAoraXhnYmVfdWZp bHRlcl9hdHRhY2goc3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIpCit7CisJYWRhcHRlci0+dWZpbHRl ci5jZGV2ID0gbWFrZV9kZXYoJmNkZXZzdywgYWRhcHRlci0+aWZwLT5pZl9kdW5pdCwKKwkgICAg VUlEX1JPT1QsIEdJRF9XSEVFTCwgMDYwMCwgIiVzIiwgaWZfbmFtZShhZGFwdGVyLT5pZnApKTsK KwlpZiAoYWRhcHRlci0+dWZpbHRlci5jZGV2ID09IE5VTEwpCisJCXJldHVybiAoRU5PTUVNKTsK KworCWFkYXB0ZXItPnVmaWx0ZXIuY2Rldi0+c2lfZHJ2MSA9ICh2b2lkICopYWRhcHRlcjsKKwkJ CisJbXR4X2luaXQoJmFkYXB0ZXItPnVmaWx0ZXIubXR4LCAidWZpbHRlcl9tdHgiLCBOVUxMLCBN VFhfREVGKTsKKwlUQUlMUV9JTklUKCZhZGFwdGVyLT51ZmlsdGVyLmxpc3QpOworCWlmIChpeGdi ZV9jb29wZXJhdGl2ZV9hdHIpIHsKKwkJYWRhcHRlci0+dWZpbHRlci5oYXNoID0gaGFzaGluaXQo dWZpbHRlcl9oYXNoX3NpemUsIE1fREVWQlVGLAorCQkJJmFkYXB0ZXItPnVmaWx0ZXIuaGFzaG1h c2spOworCQlybV9pbml0X2ZsYWdzKCZhZGFwdGVyLT51ZmlsdGVyLmhhc2hsb2NrLCAidWZpbHRl cl9oYXNobG9jayIsIAorCQkJUk1fTk9XSVRORVNTKTsKKwl9CisgICAgICAgIFNZU0NUTF9BRERf SU5UKGRldmljZV9nZXRfc3lzY3RsX2N0eChhZGFwdGVyLT5kZXYpLAorCQkJU1lTQ1RMX0NISUxE UkVOKGRldmljZV9nZXRfc3lzY3RsX3RyZWUoYWRhcHRlci0+ZGV2KSksCisJCQlPSURfQVVUTywg InVmaWx0ZXJfaGFzaF9zaXplIiwgQ1RMVFlQRV9JTlR8Q1RMRkxBR19SRCwKKwkJCSZ1ZmlsdGVy X2hhc2hfc2l6ZSwgMjAsICJ1ZmlsdGVyIGhhc2h0YWJsZSBzaXplIik7CisgICAgICAgIFNZU0NU TF9BRERfSU5UKGRldmljZV9nZXRfc3lzY3RsX2N0eChhZGFwdGVyLT5kZXYpLAorCQkJU1lTQ1RM X0NISUxEUkVOKGRldmljZV9nZXRfc3lzY3RsX3RyZWUoYWRhcHRlci0+ZGV2KSksCisJCQlPSURf QVVUTywgImNvb3BlcmF0aXZlX2F0ciIsIENUTFRZUEVfSU5UfENUTEZMQUdfUkQsCisJCQkmaXhn YmVfY29vcGVyYXRpdmVfYXRyLCAyMCwgImNvb3BlcmF0aXZlIEFUUiIpOworCisJcmV0dXJuICgw KTsKK30KKworaW50CitpeGdiZV91ZmlsdGVyX2RldGFjaChzdHJ1Y3QgYWRhcHRlciAqYWRhcHRl cikKK3sKKwlsaXN0X2ZyZWVhbGwoJmFkYXB0ZXItPnVmaWx0ZXIpOworCWlmIChpeGdiZV9jb29w ZXJhdGl2ZV9hdHIpIHsKKwkJcm1fZGVzdHJveSgmYWRhcHRlci0+dWZpbHRlci5oYXNobG9jayk7 CisJCWhhc2hkZXN0cm95KGFkYXB0ZXItPnVmaWx0ZXIuaGFzaCwgTV9ERVZCVUYsIAorCQkJYWRh cHRlci0+dWZpbHRlci5oYXNobWFzayk7CisJfQorCW10eF9kZXN0cm95KCZhZGFwdGVyLT51Zmls dGVyLm10eCk7CisJaWYgKGFkYXB0ZXItPnVmaWx0ZXIuY2RldikKKwkJZGVzdHJveV9kZXYoYWRh cHRlci0+dWZpbHRlci5jZGV2KTsKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitpeGdi ZV91ZmlsdGVyX29wZW4oc3RydWN0IGNkZXYgKmRldiwgaW50IGZsYWdzLCBpbnQgZm1wLCBzdHJ1 Y3QgdGhyZWFkICp0ZCkKK3sKKyAgICAgICByZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50Citp eGdiZV91ZmlsdGVyX2Nsb3NlKHN0cnVjdCBjZGV2ICpkZXYsIGludCBmbGFncywgaW50IGZtdCwg c3RydWN0IHRocmVhZCAqdGQpCit7CisgICAgICAgcmV0dXJuICgwKTsKK30KKworc3RhdGljIGlu dAoraXhnYmVfdWZpbHRlcl9pb2N0bChzdHJ1Y3QgY2RldiAqZGV2LCB1bnNpZ25lZCBsb25nIGNt ZCwgY2FkZHJfdCBkYXRhLAorICAgIGludCBmZmxhZywgc3RydWN0IHRocmVhZCAqdGQpCit7CisJ c3RydWN0IGFkYXB0ZXIgKmFkYXB0ZXIgPSAoc3RydWN0IGFkYXB0ZXIgKilkZXYtPnNpX2RydjE7 CisJc3RydWN0IGl4Z2JlX3VmaWx0ZXIgKnVmaWx0ZXIgPSAmYWRhcHRlci0+dWZpbHRlcjsKKwlp bnQgZXJyb3IgPSAwOworCisJaWYgKHByaXZfY2hlY2sodGQsIFBSSVZfRFJJVkVSKSkgeworCQly ZXR1cm4gKEVQRVJNKTsKKwl9CisKKwlpZiAoIWl4Z2JlX2Nvb3BlcmF0aXZlX2F0ciAmJiBpeGdi ZV9hdHJfc2FtcGxlX3JhdGUpCisJCXJldHVybiAoRU5PREVWKTsKKworCW10eF9sb2NrKCZ1Zmls dGVyLT5tdHgpOworCXN3aXRjaCAoY21kKSB7CisJY2FzZSBJWEdCRV9BRERfU0lHRklMVEVSOiB7 CisJCXN0cnVjdCB1ZmlsdGVyX2VudHJ5ICplID0gKHN0cnVjdCB1ZmlsdGVyX2VudHJ5ICopZGF0 YTsKKwkJc3RydWN0IHVmaWx0ZXJfa2VudHJ5ICprZTsKKwkJdW5pb24gaXhnYmVfYXRyX2hhc2hf ZHdvcmQgaW5wdXQgPSB7LmR3b3JkID0gMH07CisJCXVuaW9uIGl4Z2JlX2F0cl9oYXNoX2R3b3Jk IGNvbW1vbiA9IHsuZHdvcmQgPSAwfTsKKworCQlzd2l0Y2ggKGUtPnByb3RvKSB7CisJCWNhc2Ug VUZJTFRFUl9QUk9UT19UQ1BWNDoKKwkJCWlucHV0LmZvcm1hdHRlZC5mbG93X3R5cGUgXj0gSVhH QkVfQVRSX0ZMT1dfVFlQRV9UQ1BWNDsKKwkJCWJyZWFrOworCQljYXNlIFVGSUxURVJfUFJPVE9f VURQVjQ6CisJCQlpbnB1dC5mb3JtYXR0ZWQuZmxvd190eXBlIF49IElYR0JFX0FUUl9GTE9XX1RZ UEVfVURQVjQ7CisJCQlicmVhazsKKwkJZGVmYXVsdDoKKwkJCWVycm9yID0gRUlOVkFMOworCQkJ Z290byBvdXQ7CisJCX0KKwkJY29tbW9uLnBvcnQuc3JjIF49IGh0b25zKGUtPnNyY19wb3J0KTsK KwkJY29tbW9uLnBvcnQuZHN0IF49IGh0b25zKGUtPmRzdF9wb3J0KTsKKwkJY29tbW9uLmZsZXhf Ynl0ZXMgXj0gaHRvbnMoRVRIRVJUWVBFX0lQKTsKKwkJY29tbW9uLmlwIF49IGUtPnNyY19pcC5z X2FkZHIgXiBlLT5kc3RfaXAuc19hZGRyOworCisJCWtlID0gbWFsbG9jKHNpemVvZigqa2UpLCBN X0RFVkJVRiwgTV9OT1dBSVQgfCBNX1pFUk8pOworCQlpZiAoIWtlKSB7CisJCQllcnJvciA9IEVO T01FTTsKKwkJCWdvdG8gb3V0OworCQl9CisJCW1lbWNweSgma2UtPmUsIGUsIHNpemVvZihrZS0+ ZSkpOworCQlrZS0+ZS5pZCA9IHVmaWx0ZXItPm5leHRfaWQrKzsKKwkJa2UtPmlucHV0ID0gaW5w dXQ7CisJCWtlLT5jb21tb24gPSBjb21tb247CisJCWlmIChpeGdiZV9jb29wZXJhdGl2ZV9hdHIp IHsKKwkJCWtlLT5oYXNoID0gaXhnYmVfYXRyX2NvbXB1dGVfc2lnX2hhc2hfODI1OTkoaW5wdXQs IAorCQkJCWNvbW1vbik7CisJCQloYXNoX2luc2VydCh1ZmlsdGVyLCBrZSk7CisJCX0KKwkJbGlz dF9pbnNlcnQodWZpbHRlciwga2UpOworCQlpeGdiZV9mZGlyX2FkZF9zaWduYXR1cmVfZmlsdGVy XzgyNTk5KCZhZGFwdGVyLT5odywKKwkJCWlucHV0LCBjb21tb24sIGUtPnF1ZV9pbmRleCk7CisJ CWJyZWFrOworCX0KKwljYXNlIElYR0JFX0dFVF9TSUdGSUxURVI6IHsKKwkJc3RydWN0IHVmaWx0 ZXJfZW50cnkgKmUgPSAoc3RydWN0IHVmaWx0ZXJfZW50cnkgKilkYXRhOworCQlzdHJ1Y3QgdWZp bHRlcl9rZW50cnkgKmtlOworCisJCWtlID0gbGlzdF9maW5kKHVmaWx0ZXIsIGUtPmlkKTsKKwkJ aWYgKGtlKQorCQkJbWVtY3B5KGUsICZrZS0+ZSwgc2l6ZW9mKCplKSk7CisJCWVsc2UKKwkJCWVy cm9yID0gRU5PRU5UOworCQlicmVhazsKKwl9OworCWNhc2UgSVhHQkVfQ0xSX1NJR0ZJTFRFUjog eworCQl1bnNpZ25lZCAqaWQgPSAodW5zaWduZWQgKilkYXRhOworCQlzdHJ1Y3QgdWZpbHRlcl9r ZW50cnkgKmtlOworCisJCWtlID0gbGlzdF9maW5kKHVmaWx0ZXIsICppZCk7CisJCWlmICgha2Up IHsKKwkJCWVycm9yID0gRU5PRU5UOworCQkJZ290byBvdXQ7CisJCX0KKworCQlpZiAoaXhnYmVf Y29vcGVyYXRpdmVfYXRyKQorCQkJaGFzaF9yZW1vdmUodWZpbHRlciwga2UpOworCQlsaXN0X3Jl bW92ZSh1ZmlsdGVyLCBrZSk7CisKKwkJaXhnYmVfZmRpcl9lcmFzZV9zaWduYXR1cmVfZmlsdGVy XzgyNTk5KCZhZGFwdGVyLT5odywKKwkJCWtlLT5pbnB1dCwga2UtPmNvbW1vbik7CisJCWJyZWFr OworCX0KKwljYXNlIElYR0JFX0dFVF9TSUdGSUxURVJfTEVOOiB7CisJCXVuc2lnbmVkICppZCA9 ICh1bnNpZ25lZCAqKWRhdGE7CisJCQorCQkqaWQgPSB1ZmlsdGVyLT5uZXh0X2lkOworCQlicmVh azsKKwl9CisJZGVmYXVsdDoKKwkJZXJyb3IgPSBFT1BOT1RTVVBQOworCQlicmVhazsKKwl9CisK K291dDoKKwltdHhfdW5sb2NrKCZ1ZmlsdGVyLT5tdHgpOworCXJldHVybiAoZXJyb3IpOworfQor I2VuZGlmIC8qIElYR0JFX0ZESVIgKi8KZGlmZiAtLWdpdCBhL3N5cy9kZXYvaXhnYmUvaXhnYmVf dWZpbHRlci5oIGIvc3lzL2Rldi9peGdiZS9peGdiZV91ZmlsdGVyLmgKbmV3IGZpbGUgbW9kZSAx MDA2NDQKaW5kZXggMDAwMDAwMC4uYTJlODMzNAotLS0gL2Rldi9udWxsCisrKyBiL3N5cy9kZXYv aXhnYmUvaXhnYmVfdWZpbHRlci5oCkBAIC0wLDAgKzEsODYgQEAKKy8qKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KgorCitDb3B5cmlnaHQgKGMpIDIwMTMgVGFrdXlhIEFTQURBCitBbGwgcmlnaHRzIHJlc2VydmVk LgorCitSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3 aXRoIG9yIHdpdGhvdXQKK21vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0 IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucyBhcmUgbWV0OgorCisgMS4gUmVkaXN0cmlidXRpb25z IG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlLAor ICAgIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIu CisKKyAyLiBOZWl0aGVyIHRoZSBuYW1lIG9mIHRoZSBDaGVsc2lvIENvcnBvcmF0aW9uIG5vciB0 aGUgbmFtZXMgb2YgaXRzCisgICAgY29udHJpYnV0b3JzIG1heSBiZSB1c2VkIHRvIGVuZG9yc2Ug b3IgcHJvbW90ZSBwcm9kdWN0cyBkZXJpdmVkIGZyb20KKyAgICB0aGlzIHNvZnR3YXJlIHdpdGhv dXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbiBwZXJtaXNzaW9uLgorCitUSElTIFNPRlRXQVJFIElT IFBST1ZJREVEIEJZIFRIRSBDT1BZUklHSFQgSE9MREVSUyBBTkQgQ09OVFJJQlVUT1JTICJBUyBJ UyIKK0FORCBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVU IE5PVCBMSU1JVEVEIFRPLCBUSEUKK0lNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJ VFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCitBUkUgRElTQ0xBSU1FRC4g SU4gTk8gRVZFTlQgU0hBTEwgVEhFIENPUFlSSUdIVCBPV05FUiBPUiBDT05UUklCVVRPUlMgQkUK K0xJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVY RU1QTEFSWSwgT1IKK0NPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJ TUlURUQgVE8sIFBST0NVUkVNRU5UIE9GCitTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBM T1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MKK0lOVEVSUlVQVElPTikg SE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElO CitDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VO Q0UgT1IgT1RIRVJXSVNFKQorQVJJU0lORyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRI SVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUKK1BPU1NJQklMSVRZIE9GIFNVQ0gg REFNQUdFLgorCiskRnJlZUJTRCQKKworKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLworCisjaWZuZGVmIF9f SVhHQkVVRklMVEVSX0hfXworI2RlZmluZSBfX0lYR0JFVUZJTFRFUl9IX18KKworZW51bSB7CisJ VUZJTFRFUl9QUk9UT19UQ1BWNCwKKwlVRklMVEVSX1BST1RPX1VEUFY0Cit9OworCitzdHJ1Y3Qg dWZpbHRlcl9lbnRyeSB7CisJdW5zaWduZWQgaWQ7CisJaW50IHByb3RvOworCXN0cnVjdCBpbl9h ZGRyIHNyY19pcDsKKwlpbnQgc3JjX3BvcnQ7CisJc3RydWN0IGluX2FkZHIgZHN0X2lwOworCWlu dCBkc3RfcG9ydDsKKwlpbnQgcXVlX2luZGV4OworfTsKKworI2RlZmluZSBJWEdCRV9BRERfU0lH RklMVEVSCV9JT1coJ2knLCAweDAsIHN0cnVjdCB1ZmlsdGVyX2VudHJ5KQorI2RlZmluZSBJWEdC RV9HRVRfU0lHRklMVEVSCV9JT1dSKCdpJywgMHgxLCBzdHJ1Y3QgdWZpbHRlcl9lbnRyeSkKKyNk ZWZpbmUgSVhHQkVfQ0xSX1NJR0ZJTFRFUglfSU9XKCdpJywgMHgyLCB1bnNpZ25lZCkKKyNkZWZp bmUgSVhHQkVfR0VUX1NJR0ZJTFRFUl9MRU4gX0lPUignaScsIDB4MywgdW5zaWduZWQpCisKKyNp ZmRlZiBfS0VSTkVMCisjaWZkZWYgSVhHQkVfRkRJUgorI2luY2x1ZGUgPHN5cy9ybWxvY2suaD4K Kworc3RydWN0IHVmaWx0ZXJfa2VudHJ5IHsKKwlzdHJ1Y3QgdWZpbHRlcl9lbnRyeSBlOworCVRB SUxRX0VOVFJZKHVmaWx0ZXJfa2VudHJ5KSB0cV9saW5rOworCUxJU1RfRU5UUlkodWZpbHRlcl9r ZW50cnkpIGxpX2xpbms7CisJdW5pb24gaXhnYmVfYXRyX2hhc2hfZHdvcmQgaW5wdXQ7CisJdW5p b24gaXhnYmVfYXRyX2hhc2hfZHdvcmQgY29tbW9uOworCXUzMiBoYXNoOworfTsKKworc3RydWN0 IGl4Z2JlX3VmaWx0ZXIgeworCXN0cnVjdCBjZGV2CQkqY2RldjsKKwlUQUlMUV9IRUFEKCwgdWZp bHRlcl9rZW50cnkpIGxpc3Q7CisJc3RydWN0IG10eAkJbXR4OworCXVuc2lnbmVkCQluZXh0X2lk OworCUxJU1RfSEVBRCgsIHVmaWx0ZXJfa2VudHJ5KSAqaGFzaDsKKwl1X2xvbmcJCQloYXNobWFz azsKKwlzdHJ1Y3Qgcm1sb2NrCQloYXNobG9jazsKK307CisKK3N0cnVjdCBhZGFwdGVyOworaW50 IGl4Z2JlX3VmaWx0ZXJfYXR0YWNoKHN0cnVjdCBhZGFwdGVyICphZGFwdGVyKTsKK2ludCBpeGdi ZV91ZmlsdGVyX2RldGFjaChzdHJ1Y3QgYWRhcHRlciAqYWRhcHRlcik7CitleHRlcm4gaW50IGl4 Z2JlX2Nvb3BlcmF0aXZlX2F0cjsKK2ludCBpeGdiZV91ZmlsdGVyX2V4aXN0cyhzdHJ1Y3QgYWRh cHRlciAqYWRhcHRlciwgdTMyIGhhc2gpOworI2VuZGlmIC8qIElYR0JFX0ZESVIgKi8KKyNlbmRp ZiAvKiBfS0VSTkVMICovCisjZW5kaWYgLyogX19JWEdCRVVGSUxURVJfSF9fICovCisKZGlmZiAt LWdpdCBhL3Rvb2xzL3Rvb2xzL2l4Z2JldG9vbC9NYWtlZmlsZSBiL3Rvb2xzL3Rvb2xzL2l4Z2Jl dG9vbC9NYWtlZmlsZQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi4wNjk1ZTkz Ci0tLSAvZGV2L251bGwKKysrIGIvdG9vbHMvdG9vbHMvaXhnYmV0b29sL01ha2VmaWxlCkBAIC0w LDAgKzEsOSBAQAorIyAkRnJlZUJTRCQKKworUFJPRz0JaXhnYmV0b29sCitTUkNTPQlpeGdiZXRv b2wuYworTk9fTUFOPQorQ0ZMQUdTKz0gLUkkey5DVVJESVJ9Ly4uLy4uLy4uL3N5cy9kZXYvaXhn YmUgLUkuCitCSU5ESVI/PSAvdXNyL3NiaW4KKworLmluY2x1ZGUgPGJzZC5wcm9nLm1rPgpkaWZm IC0tZ2l0IGEvdG9vbHMvdG9vbHMvaXhnYmV0b29sL2l4Z2JldG9vbC5jIGIvdG9vbHMvdG9vbHMv aXhnYmV0b29sL2l4Z2JldG9vbC5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAu LmY1YjYxZjUKLS0tIC9kZXYvbnVsbAorKysgYi90b29scy90b29scy9peGdiZXRvb2wvaXhnYmV0 b29sLmMKQEAgLTAsMCArMSwyMzYgQEAKKy8qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgorCitDb3B5cmlnaHQg KGMpIDIwMTMsIFRha3V5YSBBU0FEQS4KK0FsbCByaWdodHMgcmVzZXJ2ZWQuCisKK1JlZGlzdHJp YnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91 dAorbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2lu ZyBjb25kaXRpb25zIGFyZSBtZXQ6CisKKyAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNv ZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UsCisgICAgdGhpcyBsaXN0 IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKworIDIuIFJlZGlz dHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJp Z2h0CisgICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2lu ZyBkaXNjbGFpbWVyIGluIHRoZQorICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVy aWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisKKyAzLiBOZWl0aGVyIHRoZSBu YW1lIG9mIHRoZSBDaGVsc2lvIENvcnBvcmF0aW9uIG5vciB0aGUgbmFtZXMgb2YgaXRzCisgICAg Y29udHJpYnV0b3JzIG1heSBiZSB1c2VkIHRvIGVuZG9yc2Ugb3IgcHJvbW90ZSBwcm9kdWN0cyBk ZXJpdmVkIGZyb20KKyAgICB0aGlzIHNvZnR3YXJlIHdpdGhvdXQgc3BlY2lmaWMgcHJpb3Igd3Jp dHRlbiBwZXJtaXNzaW9uLgorCitUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBDT1BZ UklHSFQgSE9MREVSUyBBTkQgQ09OVFJJQlVUT1JTICJBUyBJUyIKK0FORCBBTlkgRVhQUkVTUyBP UiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUK K0lNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFCitBUkUgRElTQ0xBSU1FRC4gSU4gTk8gRVZFTlQgU0hBTEwgVEhF IENPUFlSSUdIVCBPV05FUiBPUiBDT05UUklCVVRPUlMgQkUKK0xJQUJMRSBGT1IgQU5ZIERJUkVD VCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IKK0NPTlNFUVVF TlRJQUwgREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5U IE9GCitTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1Ig UFJPRklUUzsgT1IgQlVTSU5FU1MKK0lOVEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9O IEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOCitDT05UUkFDVCwgU1RSSUNUIExJ QUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKQorQVJJ U0lORyBJTiBBTlkgV0FZIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYg QURWSVNFRCBPRiBUSEUKK1BPU1NJQklMSVRZIE9GIFNVQ0ggREFNQUdFLgorCisKKyoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKi8KKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQi KTsKKworI2luY2x1ZGUgPHN0ZGlvLmg+CisjaW5jbHVkZSA8c3RyaW5nLmg+CisjaW5jbHVkZSA8 ZmNudGwuaD4KKyNpbmNsdWRlIDxlcnJuby5oPgorI2luY2x1ZGUgPHN0ZGxpYi5oPgorI2luY2x1 ZGUgPGxpbWl0cy5oPgorI2luY2x1ZGUgPHVuaXN0ZC5oPgorI2luY2x1ZGUgPHN5cy90eXBlcy5o PgorI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KKyNpbmNsdWRlIDxuZXRpbmV0L2luLmg+CisjaW5j bHVkZSA8YXJwYS9pbmV0Lmg+CisjaW5jbHVkZSA8c3lzL2lvY3RsLmg+CisjaW5jbHVkZSA8c3lz L3N5c2N0bC5oPgorI2luY2x1ZGUgPGl4Z2JlX3VmaWx0ZXIuaD4KKworc3RhdGljIHZvaWQKK3Vz YWdlKHZvaWQpCit7CisJZnByaW50ZihzdGRlcnIsICJVc2FnZTogaXhnYmV0b29sIDxpZm5hbWU+ IFtvcGVyYXRpb25dXG4iKTsKKwlmcHJpbnRmKHN0ZGVyciwgIlx0YWRkX3NpZ19maWx0ZXIgPHBy b3RvPiA8c3JjX2lwPiA8c3JjX3BvcnQ+IDxkc3RfaXA+IDxkc3RfcG9ydD4gPHF1ZV9pbmRleD5c biIpOworCWZwcmludGYoc3RkZXJyLCAiXHRzaG93X3NpZ19maWx0ZXJcbiIpOworCWZwcmludGYo c3RkZXJyLCAiXHRkZWxfc2lnX2ZpbHRlciA8aWQ+XG4iKTsKK30KKworc3RhdGljIGludCAKK2Fk ZF9zaWdfZmlsdGVyKGludCBmZCwgaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkKK3sKKwlzdHJ1Y3Qg dWZpbHRlcl9lbnRyeSBmaWx0ZXI7CisJaW50IGVycm9yOworCisJaWYgKGFyZ2MgIT0gOSkgCisJ CXJldHVybiAtMTsKKworCWlmICghc3RyY21wKGFyZ3ZbM10sICJ0Y3B2NCIpKQorCQlmaWx0ZXIu cHJvdG8gPSBVRklMVEVSX1BST1RPX1RDUFY0OworCWVsc2UgaWYgKCFzdHJjbXAoYXJndlszXSwg InVkcHY0IikpCisJCWZpbHRlci5wcm90byA9IFVGSUxURVJfUFJPVE9fVURQVjQ7CisJZWxzZQor CQlyZXR1cm4gLTE7CisJZXJyb3IgPSBpbmV0X2F0b24oYXJndls0XSwgJmZpbHRlci5zcmNfaXAp OworCWlmIChlcnJvciAhPSAxKQorCQlyZXR1cm4gZXJyb3I7CisJZXJybm8gPSAwOworCWZpbHRl ci5zcmNfcG9ydCA9IHN0cnRvbChhcmd2WzVdLCBOVUxMLCAwKTsKKwlpZiAoZXJybm8pCisJCXJl dHVybiBlcnJubzsKKwllcnJvciA9IGluZXRfYXRvbihhcmd2WzZdLCAmZmlsdGVyLmRzdF9pcCk7 CisJaWYgKGVycm9yICE9IDEpCisJCXJldHVybiBlcnJvcjsKKwllcnJubyA9IDA7CisJZmlsdGVy LmRzdF9wb3J0ID0gc3RydG9sKGFyZ3ZbN10sIE5VTEwsIDApOworCWlmIChlcnJubykKKwkJcmV0 dXJuIGVycm5vOworCWVycm5vID0gMDsKKwlmaWx0ZXIucXVlX2luZGV4ID0gc3RydG9sKGFyZ3Zb OF0sIE5VTEwsIDApOworCWlmIChlcnJubykKKwkJcmV0dXJuIGVycm5vOworCisJZXJyb3IgPSBp b2N0bChmZCwgSVhHQkVfQUREX1NJR0ZJTFRFUiwgJmZpbHRlcik7CisJaWYgKGVycm9yKSB7CisJ CXBlcnJvcigiaXhnYmV0b29sIik7CisJCWNsb3NlKGZkKTsKKwkJZXhpdCgxKTsKKwl9CisJcmV0 dXJuIDA7Cit9CisKK3N0YXRpYyBpbmxpbmUgY29uc3QgY2hhciAqCitmaWx0ZXJfcHJvdG9fc3Ry KGludCBwcm90bykKK3sKKwljb25zdCBjaGFyICpzdHI7CisKKwlzd2l0Y2ggKHByb3RvKSB7CisJ Y2FzZSBVRklMVEVSX1BST1RPX1RDUFY0OgorCQlzdHIgPSAidGNwdjQiOworCQlicmVhazsKKwlj YXNlIFVGSUxURVJfUFJPVE9fVURQVjQ6CisJCXN0ciA9ICJ1ZHB2NCI7CisJCWJyZWFrOworCWRl ZmF1bHQ6CisJCXN0ciA9ICIoaW52YWwpIjsKKwl9CisJcmV0dXJuIHN0cjsKK30KKworc3RhdGlj IGludCAKK3Nob3dfc2lnX2ZpbHRlcihpbnQgZmQsIGludCBhcmdjLCBjaGFyICphcmd2W10pCit7 CisJdW5zaWduZWQgaTsKKwl1bnNpZ25lZCBsZW47CisJaW50IGVycm9yOworCisJaWYgKGFyZ2Mg IT0gMykgCisJCXJldHVybiAtMTsKKworCWVycm9yID0gaW9jdGwoZmQsIElYR0JFX0dFVF9TSUdG SUxURVJfTEVOLCAmbGVuKTsKKwlpZiAoZXJyb3IpIHsKKwkJcGVycm9yKCJpeGdiZXRvb2wiKTsK KwkJY2xvc2UoZmQpOworCQlleGl0KDEpOworCX0KKworCWZvciAoaSA9IDA7IGkgPCBsZW47IGkr KykgeworCQlzdHJ1Y3QgdWZpbHRlcl9lbnRyeSBmaWx0ZXI7CisKKwkJZmlsdGVyLmlkID0gaTsK KwkJZXJyb3IgPSBpb2N0bChmZCwgSVhHQkVfR0VUX1NJR0ZJTFRFUiwgJmZpbHRlcik7CisJCWlm IChlcnJvcikKKwkJCWNvbnRpbnVlOworCQlwcmludGYoImlkOiAldVxuIiwgZmlsdGVyLmlkKTsK KwkJcHJpbnRmKCJwcm90bzogJXNcbiIsIGZpbHRlcl9wcm90b19zdHIoZmlsdGVyLnByb3RvKSk7 CisJCXByaW50Zigic3JjX2lwOiAlc1xuIiwgaW5ldF9udG9hKGZpbHRlci5zcmNfaXApKTsKKwkJ cHJpbnRmKCJzcmNfcG9ydDogJWRcbiIsIGZpbHRlci5zcmNfcG9ydCk7CisJCXByaW50ZigiZHN0 X2lwOiAlc1xuIiwgaW5ldF9udG9hKGZpbHRlci5kc3RfaXApKTsKKwkJcHJpbnRmKCJkc3RfcG9y dDogJWRcbiIsIGZpbHRlci5kc3RfcG9ydCk7CisJCXByaW50ZigicXVlX2luZGV4OiAlZFxuIiwg ZmlsdGVyLnF1ZV9pbmRleCk7CisJCXByaW50ZigiXG4iKTsKKwl9CisJcmV0dXJuIDA7Cit9CisK K3N0YXRpYyBpbnQgCitkZWxfc2lnX2ZpbHRlcihpbnQgZmQsIGludCBhcmdjLCBjaGFyICphcmd2 W10pCit7CisJdW5zaWduZWQgaWQ7CisJaW50IGVycm9yOworCisJaWYgKGFyZ2MgIT0gNCkgCisJ CXJldHVybiAtMTsKKworCWVycm5vID0gMDsKKwlpZCA9IHN0cnRvdWwoYXJndlszXSwgTlVMTCwg MCk7CisJaWYgKGVycm5vKQorCQlyZXR1cm4gZXJybm87CisKKwllcnJvciA9IGlvY3RsKGZkLCBJ WEdCRV9DTFJfU0lHRklMVEVSLCAmaWQpOworCWlmIChlcnJvcikgeworCQlwZXJyb3IoIml4Z2Jl dG9vbCIpOworCQljbG9zZShmZCk7CisJCWV4aXQoMSk7CisJfQorCXJldHVybiAwOworfQorCitp bnQgCittYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pCit7CisJaW50IHJldDsKKwljaGFyIGJ1 Zls2NF07CisJaW50IGZkOworCWludCBpZm5vOworCWludCBjb29wX2F0cjsKKwlpbnQgYXRyOwor CXNpemVfdCBjb29wX2F0cl9zaXplID0gc2l6ZW9mKGNvb3BfYXRyKTsKKwlzaXplX3QgYXRyX3Np emUgPSBzaXplb2YoYXRyKTsKKworCWlmIChhcmdjIDwgMykgeworCQl1c2FnZSgpOworCQlleGl0 KDEpOworCX0KKwlzbnByaW50ZihidWYsIHNpemVvZihidWYpLCAiL2Rldi8lcyIsIGFyZ3ZbMV0p OworCWlmICgoZmQgPSBvcGVuKGJ1ZiwgT19SRFdSKSkgPCAwKSB7CisJCXBlcnJvcigiaXhnYmV0 b29sIik7CisJCWV4aXQoMSk7CisJfQorCXNzY2FuZihhcmd2WzFdLCAiaXglZCIsICZpZm5vKTsK KwlzbnByaW50ZihidWYsIHNpemVvZihidWYpLCAiZGV2Lml4LiVkLmNvb3BlcmF0aXZlX2F0ciIs IGlmbm8pOworCXJldCA9IHN5c2N0bGJ5bmFtZShidWYsICZjb29wX2F0ciwgJmNvb3BfYXRyX3Np emUsIE5VTEwsIDApOworCWlmIChyZXQpIHsKKwkJcGVycm9yKCJpeGdiZXRvb2wiKTsKKwkJZXhp dCgxKTsKKwl9CisJc25wcmludGYoYnVmLCBzaXplb2YoYnVmKSwgImRldi5peC4lZC5hdHJfc2Ft cGxlX3JhdGUiLCBpZm5vKTsKKwlyZXQgPSBzeXNjdGxieW5hbWUoYnVmLCAmYXRyLCAmYXRyX3Np emUsIE5VTEwsIDApOworCWlmIChyZXQpIHsKKwkJcGVycm9yKCJpeGdiZXRvb2wiKTsKKwkJZXhp dCgxKTsKKwl9CisJaWYgKCFjb29wX2F0ciAmJiBhdHIpIHsKKwkJcHJpbnRmKCJUbyB1c2UgdXNl ciBkZWZpbmVkIGZpbHRlciwgeW91IG5lZWQgdG8gYWRkICdody5peGdiZS5jb29wZXJhdGl2ZV9h dHI9MScgb24gL2Jvb3QvbG9hZGVyLmNvbmYgYW5kIHJlYm9vdFxuIik7CisJCWNsb3NlKGZkKTsK KwkJZXhpdCgxKTsKKwl9CisJaWYgKCFzdHJjbXAoYXJndlsyXSwgImFkZF9zaWdfZmlsdGVyIikp CisJCXJldCA9IGFkZF9zaWdfZmlsdGVyKGZkLCBhcmdjLCBhcmd2KTsKKwllbHNlIGlmICghc3Ry Y21wKGFyZ3ZbMl0sICJzaG93X3NpZ19maWx0ZXIiKSkKKwkJcmV0ID0gc2hvd19zaWdfZmlsdGVy KGZkLCBhcmdjLCBhcmd2KTsKKwllbHNlIGlmICghc3RyY21wKGFyZ3ZbMl0sICJkZWxfc2lnX2Zp bHRlciIpKQorCQlyZXQgPSBkZWxfc2lnX2ZpbHRlcihmZCwgYXJnYywgYXJndik7CisJZWxzZSAK KwkJcmV0ID0gLTE7CisKKwlpZiAocmV0KQorCQl1c2FnZSgpOworCisJY2xvc2UoZmQpOworCisJ cmV0dXJuIChyZXQpOworfQorCg== --047d7bd90edecde4f304e8213c67-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 08:22:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 158A9737 for ; Mon, 7 Oct 2013 08:22:36 +0000 (UTC) (envelope-from fbsd-mbox@mail.ru) Received: from fallback6.mail.ru (fallback6.mail.ru [94.100.176.134]) by mx1.freebsd.org (Postfix) with ESMTP id BEDB12CDE for ; Mon, 7 Oct 2013 08:22:35 +0000 (UTC) Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) by fallback6.mail.ru (mPOP.Fallback_MX) with ESMTP id D16B11EDCD0E for ; Mon, 7 Oct 2013 12:22:33 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=onsHrokV9ZgMM+HVdUsEb3t3w6zSjIJQqWH7/zWKkFA=; b=P//homNa9HdsX/ylFan1DoAv7mF0MriYrFJYEsl83dKBxvGZ0Z7qE+mWnoixPFnxr3uT+G2SiPH13yd2pMHB4w7nITiuGhsEe5c5XQcW+sCShOcMuxbQtnzBcJ4Ntkqif8uWjYAPUFYyseGHqdFC6INVJ4CC4myGeKI7CqrArxg=; Received: from [212.100.132.202] (port=58559 helo=[127.0.0.1]) by smtp32.i.mail.ru with esmtpa (envelope-from ) id 1VT658-0005SG-Ts for freebsd-net@freebsd.org; Mon, 07 Oct 2013 12:22:26 +0400 Message-ID: <52526F3D.2060404@mail.ru> Date: Mon, 07 Oct 2013 12:22:21 +0400 From: fbsd-mbox User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Fwd: Problem with IPSec setup References: <524D99EB.5060508@mail.ru> In-Reply-To: <524D99EB.5060508@mail.ru> X-Forwarded-Message-Id: <524D99EB.5060508@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 08:22:36 -0000 Hi all, forwarded from questions@ 'cause no reply received and obviously none expected. Does anyone have a clue why kernel always directs ESP packets via default route (or default gateway in FIB 0), even if there are other FIBs with per-interface routes? I'm stuck with the gateway, which is connected to 2 ISPs and the necessity to configure IPSec tunnels on both external channels. Using setfib(8) I've managed to successfully establish an IKE session via both channels (using a separate instance of racoon per each channel), but the tunnel is just not working. Using IPFW's setfib option does not make any difference. Is this a bug or I'm missing some point? _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 11:06:49 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8328C8A7 for ; Mon, 7 Oct 2013 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 70A89283E for ; Mon, 7 Oct 2013 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r97B6nUI077791 for ; Mon, 7 Oct 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r97B6nY3077789 for freebsd-net@FreeBSD.org; Mon, 7 Oct 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Oct 2013 11:06:49 GMT Message-Id: <201310071106.r97B6nY3077789@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 11:06:49 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN Realtek® 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181699 net [ipsec] [patch] IPsec does scale to large SPD / SADB o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181225 net [infiniband] [patch] unloading ipoib crashes the kerne o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod f kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos p kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis p kern/165903 net mbuf leak o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl p kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 471 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 14:59:52 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1EEBD4AA for ; Mon, 7 Oct 2013 14:59:52 +0000 (UTC) (envelope-from kuzvesov@list.ru) Received: from fallback5.mail.ru (fallback5.mail.ru [94.100.176.59]) by mx1.freebsd.org (Postfix) with ESMTP id C164A2947 for ; Mon, 7 Oct 2013 14:59:51 +0000 (UTC) Received: from f150.i.mail.ru (f150.i.mail.ru [94.100.178.200]) by fallback5.mail.ru (mPOP.Fallback_MX) with ESMTP id E272BFA5B26D for ; Mon, 7 Oct 2013 18:59:48 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=list.ru; s=mail; h=Content-Type:Message-ID:Reply-To:Date:Mime-Version:Subject:To:From; bh=Sbk+i290euJ41Q93Hnw/tPXLeADMUgaqhGlZUzZcwD8=; b=Czq3xE5dyW1/rpqy7t5Cq7ibQPwkW2uIcJ+R0VAXpnW3nak+LvIqQ6pQkdrT0skSuCQ6Flvr6xsb2Q29aFJap+5KlW2KovYRoX0mVTGAr3fLK3H9WFlOlQcqsh+iyH62vfcUUH5EgctSFwNphMs+0xVOpgpk31aqslNir4c1c/c=; Received: from mail by f150.i.mail.ru with local (envelope-from ) id 1VTCHa-0007hA-HP for freebsd-net@freebsd.org; Mon, 07 Oct 2013 18:59:38 +0400 Received: from [178.169.40.77] by e.mail.ru with HTTP; Mon, 07 Oct 2013 18:59:38 +0400 From: =?UTF-8?B?S29uc3RhbnRpbiBLdXp2ZXNvdg==?= To: freebsd-net@freebsd.org Subject: =?UTF-8?B?QXNzeW1ldHJpYyBOSUMgcGVyZm9ybWFuY2UgcHJvYmxlbQ==?= Mime-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [178.169.40.77] Date: Mon, 07 Oct 2013 18:59:38 +0400 X-Priority: 3 (Normal) Message-ID: <1381157978.306226871@f150.i.mail.ru> X-Mras: Ok X-Spam: undefined Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?UTF-8?B?S29uc3RhbnRpbiBLdXp2ZXNvdg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 14:59:52 -0000 CkhlbGxvLAoKwqAgSSBoYXZlIGEgcHJvYmxlbSB3aXRoIE5JQyBwZXJmb3JtYW5jZS4gSXMgdGhp cyB0aGUgcmlnaHQgcGxhY2UgdG8gYXNrIGZvciBoZWxwPwoKLS0gCkJlc3QgcmVnYXJkcywKS29u c3RhbnRpbg== From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 15:10:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CCF2597B for ; Mon, 7 Oct 2013 15:10:16 +0000 (UTC) (envelope-from melifaro@yandex-team.ru) Received: from forward-corp1e.mail.yandex.net (forward-corp1e.mail.yandex.net [IPv6:2a02:6b8:0:202::10]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9532A29 for ; Mon, 7 Oct 2013 15:10:16 +0000 (UTC) Received: from smtpcorp4.mail.yandex.net (smtpcorp4.mail.yandex.net [95.108.252.2]) by forward-corp1e.mail.yandex.net (Yandex) with ESMTP id 2A85D640D73; Mon, 7 Oct 2013 19:10:12 +0400 (MSK) Received: from smtpcorp4.mail.yandex.net (localhost [127.0.0.1]) by smtpcorp4.mail.yandex.net (Yandex) with ESMTP id 06BFC2C0373; Mon, 7 Oct 2013 19:10:12 +0400 (MSK) Received: from dhcp170-36-red.yandex.net (dhcp170-36-red.yandex.net [95.108.170.36]) by smtpcorp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id ZXdIdAn7qJ-ACZi2rc0; Mon, 7 Oct 2013 19:10:12 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1381158612; bh=I1FWHpg0LO0W702aRo4OeCnmDHtonzwW7AqMoxutBfY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UM6li9S76dK0U4cqUHVWRwCZLJJVz7IFiyOsIhVdrKKB/NOJoW35wBrbUoOfRX8PK id9JapzdnVAS6oxa32IArxJ9WUBkf1hydGr3aPeoWEpXkXb+lJCQZcEt4KqkK+wGg0 fC/iv3pePKf3Az/HKHzQzJ4Ig/qj7FuWspV/SoZE= Authentication-Results: smtpcorp4.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Message-ID: <5252CE68.10604@yandex-team.ru> Date: Mon, 07 Oct 2013 19:08:24 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130824 Thunderbird/17.0.8 MIME-Version: 1.0 To: Konstantin Kuzvesov Subject: Re: Assymetric NIC performance problem References: <1381157978.306226871@f150.i.mail.ru> In-Reply-To: <1381157978.306226871@f150.i.mail.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:10:16 -0000 On 07.10.2013 18:59, Konstantin Kuzvesov wrote: > Hello, > > I have a problem with NIC performance. Is this the right place to ask for help? > Probably, if you are able to provide some more detailed information :) From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 15:48:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0F79C207 for ; Mon, 7 Oct 2013 15:48:02 +0000 (UTC) (envelope-from kuzvesov@list.ru) Received: from fallback8.mail.ru (fallback8.mail.ru [94.100.176.136]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF072C8D for ; Mon, 7 Oct 2013 15:48:00 +0000 (UTC) Received: from f116.i.mail.ru (f116.i.mail.ru [94.100.178.185]) by fallback8.mail.ru (mPOP.Fallback_MX) with ESMTP id 05BB040150D6 for ; Mon, 7 Oct 2013 19:44:59 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=list.ru; s=mail; h=Content-Type:Message-ID:Reply-To:Date:Mime-Version:Subject:To:From; bh=Yhtfo3ySTxUIkNiMqRMOBKOolCWThDFBDMgcgpxXTvw=; b=HPuHd//XXqKivsFSi9ydsTyS/ufVGcginTAveHnPY7SAIZEEeTTuWbLoNckAQ/KfhBYzkbONEOv/tu+Lvo+rqobWKH8s7o317oE9YyJZC6TNxAPSTaSYcloA/Rgmd0OD/pbACcMnOxuSRDg+FVtb33J01oOL904wujhbKkvyuII=; Received: from mail by f116.i.mail.ru with local (envelope-from ) id 1VTCzL-0004rt-Co for freebsd-net@freebsd.org; Mon, 07 Oct 2013 19:44:51 +0400 Received: from [178.169.40.77] by e.mail.ru with HTTP; Mon, 07 Oct 2013 19:44:51 +0400 From: =?UTF-8?B?S29uc3RhbnRpbiBLdXp2ZXNvdg==?= To: =?UTF-8?B?ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc=?= Subject: =?UTF-8?B?UmVbM106IEFzc3ltZXRyaWMgTklDIHBlcmZvcm1hbmNlIHByb2JsZW0=?= Mime-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [178.169.40.77] Date: Mon, 07 Oct 2013 19:44:51 +0400 X-Priority: 3 (Normal) Message-ID: <1381160691.954872513@f116.i.mail.ru> X-Mras: Ok X-Spam: undefined Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?UTF-8?B?S29uc3RhbnRpbiBLdXp2ZXNvdg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:48:02 -0000 CkkndmUgZ290IGEgRnJlZUJTRCBmaWxlIHNlcnZlciBydW5uaW5nIFNhbWJhLCBmaWxlIHVwbG9h ZCBzcGVlZHMgYXJlIG9rYXksIGJ1dCBkb3dubG9hZHMgYXJlIHRvbyBzbG93LgpGaXJzdCwgSSBk ZWNpZGVkIGl0IGlzIFNhbWJhJ3MgZmF1bHQsIGJ1dCB0aGVuIEkgcmFuIGlwZXJmIHRlc3RzLi4u CgpPbiBhIHdpbmRvd3MgbWFjaGluZSB3aXRoIGdpZ2FiaXQgTklDOgpaOlxpcGVyZj5pcGVyZiAt YyAxOTIuMTY4LjAuMQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KQ2xpZW50IGNvbm5lY3RpbmcgdG8gMTkyLjE2OC4wLjEsIFRDUCBw b3J0IDUwMDEKVENQIHdpbmRvdyBzaXplOiA2NC4wIEtCeXRlIChkZWZhdWx0KQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KWyAgM10g bG9jYWwgMTkyLjE2OC4wLjIgcG9ydCAxMDY0IGNvbm5lY3RlZCB3aXRoIDE5Mi4xNjguMC4xIHBv cnQgNTAwMQpbIElEXSBJbnRlcnZhbCAgICAgICBUcmFuc2ZlciAgICAgQmFuZHdpZHRoClsgIDNd ICAwLjAtMTAuMiBzZWMgIDEyLjQgTUJ5dGVzICAxMC4yIE1iaXRzL3NlYwoKWjpcaXBlcmY+aXBl cmYgLXMKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tClNlcnZlciBsaXN0ZW5pbmcgb24gVENQIHBvcnQgNTAwMQpUQ1Agd2luZG93IHNp emU6IDY0LjAgS0J5dGUgKGRlZmF1bHQpCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpbICA0XSBsb2NhbCAxOTIuMTY4LjAuMiBwb3J0 IDUwMDEgY29ubmVjdGVkIHdpdGggMTkyLjE2OC4wLjEgcG9ydCA0MTIyMApbIElEXSBJbnRlcnZh bCAgICAgICBUcmFuc2ZlciAgICAgQmFuZHdpZHRoClsgIDRdICAwLjAtMTAuMCBzZWMgICA3MTYg TUJ5dGVzICAgNjAwIE1iaXRzL3NlYwoKQW5kIG9uIGEgYW5vdGhlciB3aXRoIEZhc3RFdGhlcm5l dCBOSUM6CkM6XGlwZXJmPmlwZXJmLmV4ZSAtYyAxOTIuMTY4LjAuMQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KQ2xpZW50IGNvbm5l Y3RpbmcgdG8gMTkyLjE2OC4wLjEsIFRDUCBwb3J0IDUwMDEKVENQIHdpbmRvdyBzaXplOiA2NC4w IEtCeXRlIChkZWZhdWx0KQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KWyAgM10gbG9jYWwgMTkyLjE2OC4wLjUgcG9ydCA0NzU2IGNv bm5lY3RlZCB3aXRoIDE5Mi4xNjguMC4xIHBvcnQgNTAwMQpbIElEXSBJbnRlcnZhbCAgICAgICBU cmFuc2ZlciAgICAgQmFuZHdpZHRoClsgIDNdICAwLjAtMTAuMSBzZWMgIDExLjQgTUJ5dGVzICA5 LjQyIE1iaXRzL3NlYwoKQzpcaXBlcmY+aXBlcmYuZXhlIC1zCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpTZXJ2ZXIgbGlzdGVuaW5n IG9uIFRDUCBwb3J0IDUwMDEKVENQIHdpbmRvdyBzaXplOiA2NC4wIEtCeXRlIChkZWZhdWx0KQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KWyAgNF0gbG9jYWwgMTkyLjE2OC4wLjUgcG9ydCA1MDAxIGNvbm5lY3RlZCB3aXRoIDE5Mi4x NjguMC4xIHBvcnQgMTg1NTgKWyBJRF0gSW50ZXJ2YWwgICAgICAgVHJhbnNmZXIgICAgIEJhbmR3 aWR0aApbICA0XSAgMC4wLTEwLjAgc2VjICAgMTA2IE1CeXRlcyAgODguNSBNYml0cy9zZWMKCkJv dGggdGVzdHMgc2hvdyBzZXJ2ZXIncyBOSUMgcGVyZm9ybWFuY2UgZGVncmFkYXRpb24gdG8gYXJv dW5kIDEwTWJpdC9zIHdoZW4gdHJhZmZpYyBnb2VzIGZyb20gc2VydmVyIHRvIGNsaWVudC4gQW5k IGV2ZXJ5dGhpbmcgd29ya3MgZmluZSBpbiBvdGhlciBkaXJlY3Rpb24uCgpJIHZlcmlmaWVkIHRo ZSBjYWJsZXMgYW5kIGh1YiBieSBzaW1wbHkgY29ubmVjdGluZyBzZXJ2ZXIgYW5kIGEgdGVzdCBt YWNoaW5lIHdpdGggYSBuZXcgc2hvcnQgcGF0Y2ggY29yZC4gSSB0cmllZCB0byBjaGFuZ2Ugc2Vy dmVyJ3MgTklDIGZyb20gRC1MaW5rIERHRS01MjhUIHRvIFBsYW5ldCBFTlctOTYwNC4gQW5kIGl0 IGJlY2FtZSBldmVuIHdvcnNlIC0KIHVzaW5nIFBsYW5ldCBOSUMKwqBzcGVlZHMgc2xvd2VkIGRv d24gdG8gYXJvdW5kIDUwME1iaXQvcyB0byBzZXJ2ZXIgYW5kIHRoZSBzYW1lIDEwTWJpdC9zIHRv IGNsaWVudC4gSSB0cmllZCB0byBjaGFuZ2UgTklDJ3MgbWVkaWEgdG8gMTAwQmFzZVRYLCBpdCBk aWRuJ3QgaGVscCB0b28uIFdoYXQgZWxzZSBzaG91bGQgSSB0cnkgdG8gZml4IHRoZSBwcm9ibGVt PyBNYXliZSBteSBzeXN0ZW0gcmVxdWlyZXMgaXMganVzdCBtaXNjb25maWd1cmVkPwoKU3lzdGVt IGNvbmZpZ3VyYXRpb246Ck9TOiBGcmVlQlNEIDkuMi1yZWxlYXNlCktlcm5lbDogZ2VuZXJpYwpG aXJld2FsbDogbm9uZQovYm9vdC9sb2FkZXIuY29uZiAtIGxvYWQgemZzIG1vZHVsZXMgb25seQov ZXRjL3N5c2N0bC5jb25mIC0gZW1wdHkKTklDOiBELUxpbmsgREdFLTUyOFQgLyBQbGFuZXQgRU5X LTk2MDQKCj4gSGVsbG8sCj4KPiAgICBJIGhhdmUgYSBwcm9ibGVtIHdpdGggTklDIHBlcmZvcm1h bmNlLiBJcyB0aGlzIHRoZSByaWdodCBwbGFjZSB0byBhc2sgZm9yIGhlbHA/Cj4KwqBQcm9iYWJs eSwgaWYgeW91IGFyZSBhYmxlIHRvIHByb3ZpZGUgc29tZSBtb3JlIGRldGFpbGVkIGluZm9ybWF0 aW9uIDopCgotLSAKS29uc3RhbnRpbiBLdXp2ZXNvdgo= From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 15:50:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 487512E2 for ; Mon, 7 Oct 2013 15:50:22 +0000 (UTC) (envelope-from Eric_Van_Gyzen@dell.com) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0AEAC2CB2 for ; Mon, 7 Oct 2013 15:50:21 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.90,1051,1371099600"; d="scan'208,217";a="54573797" Message-ID: <5252D7F7.3030709@dell.com> Date: Mon, 7 Oct 2013 10:49:11 -0500 From: Eric van Gyzen Organization: Dell, Inc. User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130702 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: sys/net/radix.h: #define Free(p) for user-land Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Eric van Gyzen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:50:22 -0000 The user-land definition of the Free() macro in sys/net/radix.h is rather inconvenient. I work on a large C++ code-base, where several classes define Free() functions. This header file gets indirectly included in a few modules (via nested #includes), so we have to #undef Free to work around this macro definition. Ideally, radix.h would define a more unique name, such as R_Free(). If I were using a C code-base, you could say the same about my code, but it's C++, and Free() is already well qualified by classes and/or namespaces. Is this Free() macro considered a well-defined, widely known, and therefore mandatory part of the API, or could it be renamed to something more unique? Alternatively, could it be changed to an inline function definition, so as not to conflict with declarations in other namespaces? If any of these is possible, I'll gladly provide the blindingly trivial patch, although I don't have a commit bit. Finding in-tree consumers of this macro is difficult, due to its generic name. Its counterparts--R_Malloc and R_Zalloc--only appear in sys/net/{radix,route,rtsock}.c (on head). The recent ipfilter update removed the only [potential] in-tree user-land consumer. Eric -- *Eric van Gyzen* Senior Software Development Engineer *Dell* | Compellent *office* +1 952 562 3197 Cube J-732, 7615 Smetana Lane Eden Prairie, MN 55344 eric_van_gyzen@dell.com From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 16:03:24 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E450164E; Mon, 7 Oct 2013 16:03:24 +0000 (UTC) (envelope-from hiren@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B8ED12D91; Mon, 7 Oct 2013 16:03:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r97G3ONl065610; Mon, 7 Oct 2013 16:03:24 GMT (envelope-from hiren@freefall.freebsd.org) Received: (from hiren@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r97G3Ouc065606; Mon, 7 Oct 2013 16:03:24 GMT (envelope-from hiren) Date: Mon, 7 Oct 2013 16:03:24 GMT Message-Id: <201310071603.r97G3Ouc065606@freefall.freebsd.org> To: hiren@FreeBSD.org, hiren@FreeBSD.org, freebsd-net@FreeBSD.org From: hiren@FreeBSD.org Subject: Re: kern/177184: [bge] [patch] enable wake on lan X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:03:25 -0000 Synopsis: [bge] [patch] enable wake on lan Responsible-Changed-From-To: hiren->freebsd-net Responsible-Changed-By: hiren Responsible-Changed-When: Mon Oct 7 16:02:38 UTC 2013 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=177184 From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 16:14:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 39E00993 for ; Mon, 7 Oct 2013 16:14:51 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F09632E3F for ; Mon, 7 Oct 2013 16:14:50 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.90,1051,1371099600"; d="scan'208";a="54593297" Message-ID: <5252DDF8.1050306@vangyzen.net> Date: Mon, 7 Oct 2013 11:14:48 -0500 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130702 Thunderbird/17.0.7 MIME-Version: 1.0 To: Martin Laabs Subject: Re: IPv6 privacy extensions breaks kerberos References: <523ED730.2030900@martinlaabs.de> In-Reply-To: <523ED730.2030900@martinlaabs.de> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:14:51 -0000 On 09/22/2013 06:40, Martin Laabs wrote: > I noticed that kerberos stops working when enabling the privacy extension. > This is caused by the changing outgoing IP that does not fit to the dns > name anymore (or do not have a dns record at all) > So every host enabling the privacy extension will be unable to use kerberos > and kerberos enabled services like nfs. > This is a very problematic behavior and I would like to know if there is a > way getting around this. You can request tickets that are not limited to specific IP addresses. This is obviously not ideal. I also don't follow Kerberos development very closely, so there might be a better solution, such as changing the IP address in the ticket during a renewal, or requesting a subnet instead of an IP address. Good luck. I, for one, would like to hear if you find other options. Eric From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 22:14:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CBC5CC46 for ; Mon, 7 Oct 2013 22:14:59 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FEDC2896 for ; Mon, 7 Oct 2013 22:14:59 +0000 (UTC) Received: by mail-vb0-f41.google.com with SMTP id g17so3966030vbg.28 for ; Mon, 07 Oct 2013 15:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nnhTGA5IsigyylX45LZvcDVBKtSM16JTtH9rxQuBgwQ=; b=KZYZKiy6dKit+STCQfVDBI3apqg5kGVLTASFFiW/Sd2fi+faD3di64a4PUbD895+vX IfiiNETNpmlgZchyFWutWpVvXd1tIuGCWX66CIFtIKmfOyshegvUh/q2Gcqd8NdzS2OL eU4EJOsGqEpeWrM+AvSJtEORAWBqiMZuzRzCR++3Ko52J1Ev7nlHJzXNGE4E8Z93iysi XHgnIXKZwJqtLrKpMUeuvkYoY0DEKBvonuVjIfZh0dcYAbNd+nvQ/bVBwq5NNZ+vv47N ntKuQxPlaOoiM+HdG6loOxnIehmSiyWcZhWUdv5FAlamYPIIgHD4sfqxQQ/NmlyDR4JY 7GTw== MIME-Version: 1.0 X-Received: by 10.58.208.130 with SMTP id me2mr28647084vec.13.1381184098606; Mon, 07 Oct 2013 15:14:58 -0700 (PDT) Received: by 10.220.14.196 with HTTP; Mon, 7 Oct 2013 15:14:58 -0700 (PDT) Date: Mon, 7 Oct 2013 15:14:58 -0700 Message-ID: Subject: Problem with Lenovo SL500 From: Kurt Buff To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 22:14:59 -0000 All, This machine has for its wired port a RealTek unit: re0: port 0xe800-0xe8ff mem 0xfcfff000-0xfcffffff,0xfcfe0000-0xfcfeffff irq 19 at device 0.0 on pci12 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 00:26:18:45:77:51 I've got wireless working for iwn (thanks Adrian!), and I'm trying to use the wired NIC (re0) as an unnumbered port to monitor a mirror port on an HP switch. However, when I connect it, it shows up as only 10mbit, half-duplex on the switch, and it refuses to send packets. I've tried 'ifconfig re0 media 1000baseT -mediaopt full-duplex' with no particular luck, as it shows the following re0: flags=8802 metric 0 mtu 1500 options=8209b ether 00:26:18:45:77:51 nd6 options=29 media: Ethernet 1000baseT (10baseT/UTP ) status: active I get no output from 'tcpdump -npi re0'. I get link light, and it worked great on re0 when I did the install for FreeBSD, but no joy for capturing packets from the switch. Anyone have some thoughts to share on this? Yes, I tried using a new cable, too... Kurt From owner-freebsd-net@FreeBSD.ORG Mon Oct 7 23:57:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A520A99A for ; Mon, 7 Oct 2013 23:57:31 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F10B2F14 for ; Mon, 7 Oct 2013 23:57:31 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rr4so7823000pbb.34 for ; Mon, 07 Oct 2013 16:57:31 -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=ojZfAvZAbTqoYjOLf05JU5JXuExwOb1Z7oJN6llpYKk=; b=CRRTyS40retSGJRbUKzbIANk+P4gQtu166KQQFBH8Ng2c9RTm8154Gmk97YkBDiVdL nGWqER8lJr/1s27E8W9ym2QkCE4l7AuHfjLFSPE/jw2fTB88jQ7I/IxDxylubm9ZMv2l K1MAMkiAr0RJEPUtRV44CL7UfIXO4DcsHtp2lFSHIcKkrSooFN3mNgnlGsXO0yCQEWpx 2xzmPu9XSzbOMx6pkuWtZvFlmefdhGeIO8seTpZ9DSEEVjuUag7l0kAGryDoCECwd8Ft jq4O2RMy9T0WIPawKDeQ2Ur0cxWVx9wB8uwe1P8UJs949fSIWddHvAEcMV0EZXEvf7WG oEUA== MIME-Version: 1.0 X-Received: by 10.66.161.229 with SMTP id xv5mr89901pab.87.1381190251198; Mon, 07 Oct 2013 16:57:31 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.219.74 with HTTP; Mon, 7 Oct 2013 16:57:31 -0700 (PDT) In-Reply-To: <1381160691.954872513@f116.i.mail.ru> References: <1381160691.954872513@f116.i.mail.ru> Date: Mon, 7 Oct 2013 16:57:31 -0700 X-Google-Sender-Auth: Uy-Zh-9MNM_hysS9WCjBcbza46Q Message-ID: Subject: Re: Re[3]: Assymetric NIC performance problem From: Kevin Oberman To: Konstantin Kuzvesov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 23:57:31 -0000 On Mon, Oct 7, 2013 at 8:44 AM, Konstantin Kuzvesov wrote: > > I've got a FreeBSD file server running Samba, file upload speeds are okay, > but downloads are too slow. > First, I decided it is Samba's fault, but then I ran iperf tests... > > On a windows machine with gigabit NIC: > Z:\iperf>iperf -c 192.168.0.1 > ------------------------------------------------------------ > Client connecting to 192.168.0.1, TCP port 5001 > TCP window size: 64.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.0.2 port 1064 connected with 192.168.0.1 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.2 sec 12.4 MBytes 10.2 Mbits/sec > > Z:\iperf>iperf -s > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 64.0 KByte (default) > ------------------------------------------------------------ > [ 4] local 192.168.0.2 port 5001 connected with 192.168.0.1 port 41220 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0-10.0 sec 716 MBytes 600 Mbits/sec > > And on a another with FastEthernet NIC: > C:\iperf>iperf.exe -c 192.168.0.1 > ------------------------------------------------------------ > Client connecting to 192.168.0.1, TCP port 5001 > TCP window size: 64.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 192.168.0.5 port 4756 connected with 192.168.0.1 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.1 sec 11.4 MBytes 9.42 Mbits/sec > > C:\iperf>iperf.exe -s > ------------------------------------------------------------ > Server listening on TCP port 5001 > TCP window size: 64.0 KByte (default) > ------------------------------------------------------------ > [ 4] local 192.168.0.5 port 5001 connected with 192.168.0.1 port 18558 > [ ID] Interval Transfer Bandwidth > [ 4] 0.0-10.0 sec 106 MBytes 88.5 Mbits/sec > > Both tests show server's NIC performance degradation to around 10Mbit/s > when traffic goes from server to client. And everything works fine in other > direction. > > I verified the cables and hub by simply connecting server and a test > machine with a new short patch cord. I tried to change server's NIC from > D-Link DGE-528T to Planet ENW-9604. And it became even worse - > using Planet NIC > speeds slowed down to around 500Mbit/s to server and the same 10Mbit/s to > client. I tried to change NIC's media to 100BaseTX, it didn't help too. > What else should I try to fix the problem? Maybe my system requires is just > misconfigured? > > System configuration: > OS: FreeBSD 9.2-release > Kernel: generic > Firewall: none > /boot/loader.conf - load zfs modules only > /etc/sysctl.conf - empty > NIC: D-Link DGE-528T / Planet ENW-9604 > > > Hello, > > > > I have a problem with NIC performance. Is this the right place to ask > for help? > > > Probably, if you are able to provide some more detailed information :) > > -- > Konstantin Kuzvesov > Output from ifconfig would probably be helpful, but I'd also suggest that you capture packets (or, at least headers) for at least the start of the transfer and look at them with wireshark or some similar tool. wireshark can tell you quite a bit and, if you feed the capture into tcptrace, you can really see what is happening. (Note, wireshark provides indications of problems that can make sense to people not conversant with the gory details of TCP, though some issues may not be obvious. tcptrace output can be utterly cryptic if you don't understand a lot of the details of TCP and congestion control. Both wireshark and tcptrace are in ports and are best installed on a workstation. The tcpdump output can be used as input to both. ("tcpdump -pw FILE -i INTERFACE host ADDRESS" can do the job. Then copy the capture to the right place for analysis. But start with configuration and counters for the interface (netstat -i). -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 00:34:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1315FB39 for ; Tue, 8 Oct 2013 00:34:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DFFF22180 for ; Tue, 8 Oct 2013 00:34:05 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id bj1so8038237pad.21 for ; Mon, 07 Oct 2013 17:34:05 -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:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=zTv2/JNEVeaxsNmviMTPgowGoeNZgVXAohJZd/Z2V7w=; b=xD/JD7DHrifArpCDbJ80HdVgrhytXFzNYezKb7o4DLNTz1uDVukTGXuG+zBvTeK+Mc n6ED2Pw23pMEtUABvhuK5q4TvB2HKX5g5puU9LETKRropj1Fdla5M9lM6L4eaR1llJEw ycCWrbCvxIuWfv0wsr5QU2tFe8vajt8WBll7TnKD/SvwlwEcnCEOtdFdlkBAQFuHiPlr sd5DNVJsNMRfsnaSk2j3RXwngkdvaQufdcqL1z8KSAED3u3fhD/T+XrCKZwk6YAYbVTA XhtdVNEde0W16cAqxJTmqnnmHXa7RJ4X7dLISEdvGRPB5ImS7qtpJozF/3pUShr81bRa rbrg== X-Received: by 10.68.255.229 with SMTP id at5mr6555217pbd.130.1381192445508; Mon, 07 Oct 2013 17:34:05 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPSA id l8sm36013826pbl.22.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 07 Oct 2013 17:34:04 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 08 Oct 2013 09:33:59 +0900 From: Yonghyeon PYUN Date: Tue, 8 Oct 2013 09:33:59 +0900 To: Kurt Buff Subject: Re: Problem with Lenovo SL500 Message-ID: <20131008003359.GA3162@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 00:34:06 -0000 On Mon, Oct 07, 2013 at 03:14:58PM -0700, Kurt Buff wrote: > All, > > This machine has for its wired port a RealTek unit: > > re0: port > 0xe800-0xe8ff mem 0xfcfff000-0xfcffffff,0xfcfe0000-0xfcfeffff irq 19 > at device 0.0 on pci12 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re0: Ethernet address: 00:26:18:45:77:51 > > > I've got wireless working for iwn (thanks Adrian!), and I'm trying to > use the wired NIC (re0) as an unnumbered port to monitor a mirror port > on an HP switch. However, when I connect it, it shows up as only > 10mbit, half-duplex on the switch, and it refuses to send packets. > > I've tried 'ifconfig re0 media 1000baseT -mediaopt full-duplex' > > with no particular luck, as it shows the following > > re0: flags=8802 metric 0 mtu 1500 > options=8209b > ether 00:26:18:45:77:51 > nd6 options=29 > media: Ethernet 1000baseT (10baseT/UTP ) > status: active > > I get no output from 'tcpdump -npi re0'. I get link light, and it > worked great on re0 when I did the install for FreeBSD, but no joy for > capturing packets from the switch. It seems you didn't UP the interface. And you may have to put the interface into promiscuous mode to capture all packets(i.e. remove -p option). > > Anyone have some thoughts to share on this? Yes, I tried using a new > cable, too... > > Kurt From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 00:47:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F317F293 for ; Tue, 8 Oct 2013 00:47:32 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B3C6A2245 for ; Tue, 8 Oct 2013 00:47:32 +0000 (UTC) Received: by mail-vb0-f44.google.com with SMTP id e13so3960226vbg.31 for ; Mon, 07 Oct 2013 17:47:31 -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=7v4V3lWgwAN9rE3Kqy4qMTMNrJPdXTxv/Z9kkir+yb4=; b=0wYLk74TKEadYh8CEUw/acn3hIS4b25On/2BAForrWokEMlqT6Amw5K0TSncaG3Qpb NzpkJX7HQpfUzCcUTPoJWnPZt9nxufasVUcjl1CEfO6j02xyXGmzEoAJtQFNR5YRIahM BK/jYXyMkwUzch/uM0I8/drYwxAnJ/vUD6LRgz+I0t71eRo/3rAnUHROrNvWvz9z72dz QdSih3au6yk9k9kybf9mZmNOkIhM/FXisRCX6bW/40sAQR93raAy1jwZ4IkuZGUPPVZy hZk5ABoZ0fkEUKQVJVU/ctCLQXACLBB7rUnooahNPtK9+V5jRdJ6VOrVkSJD4iprJDQV Scdw== MIME-Version: 1.0 X-Received: by 10.220.145.132 with SMTP id d4mr28880088vcv.9.1381193251813; Mon, 07 Oct 2013 17:47:31 -0700 (PDT) Received: by 10.220.14.196 with HTTP; Mon, 7 Oct 2013 17:47:31 -0700 (PDT) In-Reply-To: <20131008003359.GA3162@michelle.cdnetworks.com> References: <20131008003359.GA3162@michelle.cdnetworks.com> Date: Mon, 7 Oct 2013 17:47:31 -0700 Message-ID: Subject: Re: Problem with Lenovo SL500 From: Kurt Buff To: pyunyh@gmail.com Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 00:47:33 -0000 Wow. What a rookie mistake. :( 'ifconfig re0 up' brought it right up. I'll add that line to rc.conf as 'ifconfig_re0="UP"' Thanks, Kurt On Mon, Oct 7, 2013 at 5:33 PM, Yonghyeon PYUN wrote: > On Mon, Oct 07, 2013 at 03:14:58PM -0700, Kurt Buff wrote: >> All, >> >> This machine has for its wired port a RealTek unit: >> >> re0: port >> 0xe800-0xe8ff mem 0xfcfff000-0xfcffffff,0xfcfe0000-0xfcfeffff irq 19 >> at device 0.0 on pci12 >> re0: Using 1 MSI-X message >> re0: ASPM disabled >> re0: Chip rev. 0x3c000000 >> re0: MAC rev. 0x00400000 >> miibus0: on re0 >> rgephy0: PHY 1 on miibus0 >> rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, >> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, >> 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, >> 1000baseT-FDX-flow-master, auto, auto-flow >> re0: Ethernet address: 00:26:18:45:77:51 >> >> >> I've got wireless working for iwn (thanks Adrian!), and I'm trying to >> use the wired NIC (re0) as an unnumbered port to monitor a mirror port >> on an HP switch. However, when I connect it, it shows up as only >> 10mbit, half-duplex on the switch, and it refuses to send packets. >> >> I've tried 'ifconfig re0 media 1000baseT -mediaopt full-duplex' >> >> with no particular luck, as it shows the following >> >> re0: flags=8802 metric 0 mtu 1500 >> options=8209b >> ether 00:26:18:45:77:51 >> nd6 options=29 >> media: Ethernet 1000baseT (10baseT/UTP ) >> status: active >> >> I get no output from 'tcpdump -npi re0'. I get link light, and it >> worked great on re0 when I did the install for FreeBSD, but no joy for >> capturing packets from the switch. > > It seems you didn't UP the interface. And you may have to put the > interface into promiscuous mode to capture all packets(i.e. remove > -p option). > >> >> Anyone have some thoughts to share on this? Yes, I tried using a new >> cable, too... >> >> Kurt From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 00:49:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 694A644E for ; Tue, 8 Oct 2013 00:49:03 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 02391226B for ; Tue, 8 Oct 2013 00:49:02 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id m15so8232009wgh.9 for ; Mon, 07 Oct 2013 17:49:01 -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=DklWDBtinuHUY0zJndPLnI+LIKyCv9VnI2dFsiLVT/c=; b=MLJJhTcRiDupq3ASkSqxBJCfkNKNYLZLyaAJG4PpA0/6Ylh4cYpOhmy4u1vU6Wlvqs rtohIvhZO3IoX1M3lQiWIrIIslLwc5zkqRlsc1YK/6q54bstbkLfDB+jHmPBUpjcAmo3 uri2DtMFxL94A8xqavhjTzxhstGnWnqUVCOVozAgkZDyYebvGb499wG8bz4EAW1beeeN Gj8d3feusymnWyt1Vu/O/v4eghQUH6ZrtEmDb6Ewgp3dLcDuN0w4aiJ6QCc/3uiKzuVy DM0v8RKS22e1M8ApTyg0kNeBcB7o7jflo0TgF0LNr0AO4o6JpHP38Y1m8GatB5W92hVq IvbA== MIME-Version: 1.0 X-Received: by 10.194.77.167 with SMTP id t7mr26912949wjw.27.1381193341372; Mon, 07 Oct 2013 17:49:01 -0700 (PDT) Received: by 10.227.236.138 with HTTP; Mon, 7 Oct 2013 17:49:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 Oct 2013 17:49:01 -0700 Message-ID: Subject: Re: Adding Flow Director sysctls to ixgbe(4) (was: netmap: traffic distribution) From: hiren panchasara To: Takuya ASADA Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 00:49:03 -0000 On Mon, Oct 7, 2013 at 12:01 AM, Takuya ASADA wrote: > Hi, > > This is updated version of "ixgbetool" patch. I will try to give this a try tomorrow. Cheers, Hiren > Here's improved feature list: > - signature filter list feature available > - user-defined filter can be use with an ATR. > To enable it, add "hw.ixgbe.cooperative_atr=1" on /boot/loader.conf > > Usage is as follows: > ixgbetool [operation] > add_sig_filter > > show_sig_filter > del_sig_filter > > > 2013/9/30 Takuya ASADA > >> Hi, >> >> I just implemented device specific ioctl with device specific >> configuration tool. >> It still doesn't support some important features such as: >> - FDIR enable / disable via sysctl or tunable params >> - ATR enable / disable via sysctl or tunable params >> - IPv6 support on signature filter >> - signature filter list >> - support perfect filter >> But, at least it can configure signature filter manually. >> >> Usage is as follows: >> Usage: ixgbetool [operation] >> add_sig_filter >> del_sig_filter >> >> >> 2013/9/28 hiren panchasara >> >>> >>> >>> >>> On Fri, Sep 27, 2013 at 1:58 AM, Takuya ASADA wrote: >>> >>>> 2013/9/27 Adrian Chadd >>>> >>>>> On 27 September 2013 00:43, hiren panchasara < >>>>> hiren.panchasara@gmail.com> wrote: >>>>> >>>>> >>>>>> Takuya, >>>>>> >>>>>> I see a lot of responses/comments on proposed changes. Was anything >>>>>> decided >>>>>> at the end of it? As far as I can tell, its still not committed to the >>>>>> tree. >>>>>> >>>>> >>>>> I'd rather see an ioctl API for that chipset and then have a separate >>>>> tool program it for now. >>>>> >>>> >>>> Ah, like cxgbetool and cxgbe? (it has device specific tool and ioctls) >>>> http://svnweb.freebsd.org/base/head/tools/tools/cxgbetool/ >>>> >>> >>> Something like this for ixgbe would be nice to start with, imo. >>> >>> Cheers, >>> Hiren >>> >>>> http://svnweb.freebsd.org/base/head/sys/dev/cxgb/ >>>> >>>> >>>>> So, how bout we hack that up? :) >>>>> >>>> >>>> Sound's interesting ;-) >>>> Could you tell me more detail about your idea? >>>> >>>> >>> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 09:34:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CFECE346 for ; Tue, 8 Oct 2013 09:34:06 +0000 (UTC) (envelope-from kuzvesov@list.ru) Received: from fallback8.mail.ru (fallback8.mail.ru [94.100.176.136]) by mx1.freebsd.org (Postfix) with ESMTP id CF758230F for ; Tue, 8 Oct 2013 09:34:05 +0000 (UTC) Received: from f224.i.mail.ru (f224.i.mail.ru [94.100.178.211]) by fallback8.mail.ru (mPOP.Fallback_MX) with ESMTP id 8253E4030099 for ; Tue, 8 Oct 2013 13:33:10 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=list.ru; s=mail; h=References:Content-Type:Message-ID:Reply-To:Date:Mime-Version:Subject:Cc:To:From; bh=47Uy4G/ss5vKNWD+s1qEMzcYHxgSTGivKKvGcC4QKy4=; b=gKUYFsdqHzNDwn6HU2BHSvbCnf7EYfsI/jqMMea+sliB+sgHyvS+SZagOWFf2PcTzE1v4WyHkrvBQcmWUS30YBpaWhh78In3tKZ340TrcHXLakdtnPTiML/bm157F7Gsr7kftZGCGsjK//G6wA0tX1PBobPfRPcjZyQOKxREQoE=; Received: from mail by f224.i.mail.ru with local (envelope-from ) id 1VTTf3-0008Cf-CC; Tue, 08 Oct 2013 13:33:01 +0400 Received: from [178.169.40.77] by e.mail.ru with HTTP; Tue, 08 Oct 2013 13:33:01 +0400 From: =?UTF-8?B?S29uc3RhbnRpbiBLdXp2ZXNvdg==?= To: =?UTF-8?B?S2V2aW4gT2Jlcm1hbg==?= Subject: =?UTF-8?B?UmVbNV06IEFzc3ltZXRyaWMgTklDIHBlcmZvcm1hbmNlIHByb2JsZW0=?= Mime-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [178.169.40.77] Date: Tue, 08 Oct 2013 13:33:01 +0400 X-Priority: 3 (Normal) Message-ID: <1381224781.77122356@f224.i.mail.ru> X-Mras: Ok X-Spam: undefined References: <1381160691.954872513@f116.i.mail.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?UTF-8?B?ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc=?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?UTF-8?B?S29uc3RhbnRpbiBLdXp2ZXNvdg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 09:34:07 -0000 Ck9uIE1vbiwgT2N0ICA3LCAyMDEzIGF0IDE2OjU3IC0wNzowMCwgS2V2aW4gT2Jlcm1hbiA8cmtv YmVybWFuQGdtYWlsLmNvbT4gd3JvdGU6Cj5PbiBNb24sIE9jdCA3LCAyMDEzIGF0IDg6NDQgQU0s IEtvbnN0YW50aW4gS3V6dmVzb3YgIDwga3V6dmVzb3ZAbGlzdC5ydSA+IHdyb3RlOgo+Pgo+Pkkn dmUgZ290IGEgRnJlZUJTRCBmaWxlIHNlcnZlciBydW5uaW5nIFNhbWJhLCBmaWxlIHVwbG9hZCBz cGVlZHMgYXJlIG9rYXksIGJ1dCBkb3dubG9hZHMgYXJlIHRvbyBzbG93Lgo+PkZpcnN0LCBJIGRl Y2lkZWQgaXQgaXMgU2FtYmEncyBmYXVsdCwgYnV0IHRoZW4gSSByYW4gaXBlcmYgdGVzdHMuLi4K Pj4KPj5PbiBhIHdpbmRvd3MgbWFjaGluZSB3aXRoIGdpZ2FiaXQgTklDOgo+Plo6XGlwZXJmPmlw ZXJmIC1jIDE5Mi4xNjguMC4xCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4+Q2xpZW50IGNvbm5lY3RpbmcgdG8gMTkyLjE2OC4w LjEsIFRDUCBwb3J0IDUwMDEKPj5UQ1Agd2luZG93IHNpemU6IDY0LjAgS0J5dGUgKGRlZmF1bHQp Cj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCj4+WyDCoDNdIGxvY2FsIDE5Mi4xNjguMC4yIHBvcnQgMTA2NCBjb25uZWN0ZWQgd2l0 aCAxOTIuMTY4LjAuMSBwb3J0IDUwMDEKPj5bIElEXSBJbnRlcnZhbCDCoCDCoCDCoCBUcmFuc2Zl ciDCoCDCoCBCYW5kd2lkdGgKPj5bIMKgM10gwqAwLjAtMTAuMiBzZWMgwqAxMi40IE1CeXRlcyDC oDEwLjIgTWJpdHMvc2VjCj4+Cj4+WjpcaXBlcmY+aXBlcmYgLXMKPj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj5TZXJ2ZXIgbGlz dGVuaW5nIG9uIFRDUCBwb3J0IDUwMDEKPj5UQ1Agd2luZG93IHNpemU6IDY0LjAgS0J5dGUgKGRl ZmF1bHQpCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCj4+WyDCoDRdIGxvY2FsIDE5Mi4xNjguMC4yIHBvcnQgNTAwMSBjb25uZWN0 ZWQgd2l0aCAxOTIuMTY4LjAuMSBwb3J0IDQxMjIwCj4+WyBJRF0gSW50ZXJ2YWwgwqAgwqAgwqAg VHJhbnNmZXIgwqAgwqAgQmFuZHdpZHRoCj4+WyDCoDRdIMKgMC4wLTEwLjAgc2VjIMKgIDcxNiBN Qnl0ZXMgwqAgNjAwIE1iaXRzL3NlYwo+Pgo+PkFuZCBvbiBhIGFub3RoZXIgd2l0aCBGYXN0RXRo ZXJuZXQgTklDOgo+PkM6XGlwZXJmPmlwZXJmLmV4ZSAtYyAxOTIuMTY4LjAuMQo+Pi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+PkNs aWVudCBjb25uZWN0aW5nIHRvIDE5Mi4xNjguMC4xLCBUQ1AgcG9ydCA1MDAxCj4+VENQIHdpbmRv dyBzaXplOiA2NC4wIEtCeXRlIChkZWZhdWx0KQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+PlsgwqAzXSBsb2NhbCAxOTIuMTY4 LjAuNSBwb3J0IDQ3NTYgY29ubmVjdGVkIHdpdGggMTkyLjE2OC4wLjEgcG9ydCA1MDAxCj4+WyBJ RF0gSW50ZXJ2YWwgwqAgwqAgwqAgVHJhbnNmZXIgwqAgwqAgQmFuZHdpZHRoCj4+WyDCoDNdIMKg MC4wLTEwLjEgc2VjIMKgMTEuNCBNQnl0ZXMgwqA5LjQyIE1iaXRzL3NlYwo+Pgo+PkM6XGlwZXJm PmlwZXJmLmV4ZSAtcwo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQo+PlNlcnZlciBsaXN0ZW5pbmcgb24gVENQIHBvcnQgNTAwMQo+ PlRDUCB3aW5kb3cgc2l6ZTogNjQuMCBLQnl0ZSAoZGVmYXVsdCkKPj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj5bIMKgNF0gbG9j YWwgMTkyLjE2OC4wLjUgcG9ydCA1MDAxIGNvbm5lY3RlZCB3aXRoIDE5Mi4xNjguMC4xIHBvcnQg MTg1NTgKPj5bIElEXSBJbnRlcnZhbCDCoCDCoCDCoCBUcmFuc2ZlciDCoCDCoCBCYW5kd2lkdGgK Pj5bIMKgNF0gwqAwLjAtMTAuMCBzZWMgwqAgMTA2IE1CeXRlcyDCoDg4LjUgTWJpdHMvc2VjCj4+ Cj4+Qm90aCB0ZXN0cyBzaG93IHNlcnZlcidzIE5JQyBwZXJmb3JtYW5jZSBkZWdyYWRhdGlvbiB0 byBhcm91bmQgMTBNYml0L3Mgd2hlbiB0cmFmZmljIGdvZXMgZnJvbSBzZXJ2ZXIgdG8gY2xpZW50 LiBBbmQgZXZlcnl0aGluZyB3b3JrcyBmaW5lIGluIG90aGVyIGRpcmVjdGlvbi4KPj4KPj5JIHZl cmlmaWVkIHRoZSBjYWJsZXMgYW5kIGh1YiBieSBzaW1wbHkgY29ubmVjdGluZyBzZXJ2ZXIgYW5k IGEgdGVzdCBtYWNoaW5lIHdpdGggYSBuZXcgc2hvcnQgcGF0Y2ggY29yZC4gSSB0cmllZCB0byBj aGFuZ2Ugc2VydmVyJ3MgTklDIGZyb20gRC1MaW5rIERHRS01MjhUIHRvIFBsYW5ldCBFTlctOTYw NC4gQW5kIGl0IGJlY2FtZSBldmVuIHdvcnNlIC0KPj7CoHVzaW5nIFBsYW5ldCBOSUMKPj7CoHNw ZWVkcyBzbG93ZWQgZG93biB0byBhcm91bmQgNTAwTWJpdC9zIHRvIHNlcnZlciBhbmQgdGhlIHNh bWUgMTBNYml0L3MgdG8gY2xpZW50LiBJIHRyaWVkIHRvIGNoYW5nZSBOSUMncyBtZWRpYSB0byAx MDBCYXNlVFgsIGl0IGRpZG4ndCBoZWxwIHRvby4gV2hhdCBlbHNlIHNob3VsZCBJIHRyeSB0byBm aXggdGhlIHByb2JsZW0/IE1heWJlIG15IHN5c3RlbSByZXF1aXJlcyBpcyBqdXN0IG1pc2NvbmZp Z3VyZWQ/Cj4+Cj4+U3lzdGVtIGNvbmZpZ3VyYXRpb246Cj4+T1M6IEZyZWVCU0QgOS4yLXJlbGVh c2UKPj5LZXJuZWw6IGdlbmVyaWMKPj5GaXJld2FsbDogbm9uZQo+Pi9ib290L2xvYWRlci5jb25m IC0gbG9hZCB6ZnMgbW9kdWxlcyBvbmx5Cj4+L2V0Yy9zeXNjdGwuY29uZiAtIGVtcHR5Cj4+TklD OiBELUxpbmsgREdFLTUyOFQgLyBQbGFuZXQgRU5XLTk2MDQKPj7CoMKgCj5PdXRwdXQgZnJvbSBp ZmNvbmZpZyB3b3VsZCBwcm9iYWJseSBiZSBoZWxwZnVsLCBidXQgSSdkIGFsc28gCnN1Z2dlc3Qg dGhhdCB5b3UgY2FwdHVyZSBwYWNrZXRzIChvciwgYXQgbGVhc3QgaGVhZGVycykgZm9yIGF0IGxl YXN0IHRoZQogc3RhcnQgb2YgdGhlIHRyYW5zZmVyIGFuZCBsb29rIGF0IHRoZW0gd2l0aCB3aXJl c2hhcmsgb3Igc29tZSBzaW1pbGFyIAp0b29sLiAKPgo+d2lyZXNoYXJrIGNhbiB0ZWxsIHlvdSBx dWl0ZSBhIGJpdCBhbmQsIGlmIHlvdSBmZWVkIHRoZSAKY2FwdHVyZSBpbnRvIHRjcHRyYWNlLCB5 b3UgY2FuIHJlYWxseSBzZWUgd2hhdCBpcyBoYXBwZW5pbmcuIChOb3RlLCAKd2lyZXNoYXJrIHBy b3ZpZGVzIGluZGljYXRpb25zIG9mIHByb2JsZW1zIHRoYXQgY2FuIG1ha2Ugc2Vuc2UgdG8gcGVv cGxlCiBub3QgY29udmVyc2FudCB3aXRoIHRoZSBnb3J5IGRldGFpbHMgb2YgVENQLCB0aG91Z2gg c29tZSBpc3N1ZXMgbWF5IG5vdCAKYmUgb2J2aW91cy4gdGNwdHJhY2Ugb3V0cHV0IGNhbiBiZSB1 dHRlcmx5IGNyeXB0aWMgaWYgeW91IGRvbid0IAp1bmRlcnN0YW5kIGEgbG90IG9mIHRoZSBkZXRh aWxzIG9mIFRDUCBhbmQgY29uZ2VzdGlvbiBjb250cm9sLgo+Cj5Cb3RoCiB3aXJlc2hhcmsgYW5k IHRjcHRyYWNlIGFyZSBpbiBwb3J0cyBhbmQgYXJlIGJlc3QgaW5zdGFsbGVkIG9uIGEgCndvcmtz dGF0aW9uLiBUaGUgdGNwZHVtcCBvdXRwdXQgY2FuIGJlIHVzZWQgYXMgaW5wdXQgdG8gYm90aC4g KCJ0Y3BkdW1wIAotcHcgRklMRSAtaSBJTlRFUkZBQ0UgaG9zdCBBRERSRVNTIiBjYW4gZG8gdGhl IGpvYi4gVGhlbiBjb3B5IHRoZSAKY2FwdHVyZSB0byB0aGUgcmlnaHQgcGxhY2UgZm9yIGFuYWx5 c2lzLiBCdXQgc3RhcnQgd2l0aCBjb25maWd1cmF0aW9uIAphbmQgY291bnRlcnMgZm9yIHRoZSBp bnRlcmZhY2UgKG5ldHN0YXQgLWkpLgo+LS0gCj5SLiBLZXZpbiBPYmVybWFuLCBOZXR3b3JrIEVu Z2luZWVyCj5FLW1haWw6ICBya29iZXJtYW5AZ21haWwuY29tCgpTdGFydGluZyB3aXRoIGNvbmZp Z3VyYXRpb24gYW5kIGNvdW50ZXJzLgpGaXJzdCBvZiBhbGwgSSByYW4gdGhlIHRlc3QgYWdhaW4s IHNpbmNlLCBpbWhvLCBpdCdzIHBvaW50bGVzcyB0byBjb25zaWRlciBhbnkgY291bnRlciBvbiBh IGp1c3QgcmVib290ZWQgbWFjaGluZToKI2lwZXJmIC1zCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpTZXJ2ZXIgbGlzdGVuaW5nIG9u IFRDUCBwb3J0IDUwMDEKVENQIHdpbmRvdyBzaXplOiA2NC4wIEtCeXRlIChkZWZhdWx0KQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K WyAgNF0gbG9jYWwgMTkyLjE2OC4wLjEgcG9ydCA1MDAxIGNvbm5lY3RlZCB3aXRoIDE5Mi4xNjgu MC42IHBvcnQgMzg5MgpbIElEXSBJbnRlcnZhbCAgICAgICBUcmFuc2ZlciAgICAgQmFuZHdpZHRo ClsgIDRdICAwLjAtMTAuMyBzZWMgIDguNTAgTUJ5dGVzICA2LjkxIE1iaXRzL3NlYwoKI25ldHN0 YXQgLUkgcmUwCk5hbWUgICAgTXR1IE5ldHdvcmsgICAgICAgQWRkcmVzcyAgICAgICAgICAgICAg SXBrdHMgSWVycnMgSWRyb3AgICAgT3BrdHMgT2VycnMgIENvbGwKcmUwICAgIDE1MDAgPExpbmsj MT4gICAgICB4eDp4eDp4eDp4eDp4eDp4eCAgMzg4NTExOCAgICAgMCAgICAgMCAgNjkyODUyNCAg ICAgMCAgICAgMApyZTAgICAgMTUwMCAxOTIuMTY4LjAuMCAgIG5zLmxhbiAgICAgICAgICAgICAz NDA4NzcwICAgICAtICAgICAtICA2MDkxNTI0ICAgICAtICAgICAtCgojaWZjb25maWcgcmUwCnJl MDogZmxhZ3M9ODg0MzxVUCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVYLE1VTFRJQ0FTVD4gbWV0 cmljIDAgbXR1IDE1MDAKb3B0aW9ucz04MjA5YjxSWENTVU0sVFhDU1VNLFZMQU5fTVRVLFZMQU5f SFdUQUdHSU5HLFZMQU5fSFdDU1VNLFdPTF9NQUdJQyxMSU5LU1RBVEU+CmV0aGVyIHh4Onh4Onh4 Onh4Onh4Onh4CmluZXQgMTkyLjE2OC4wLjEgbmV0bWFzayAweGZmZmZmZjAwIGJyb2FkY2FzdCAx OTIuMTY4LjAuMjU1Cm5kNiBvcHRpb25zPTI5PFBFUkZPUk1OVUQsSUZESVNBQkxFRCxBVVRPX0xJ TktMT0NBTD4KbWVkaWE6IEV0aGVybmV0IGF1dG9zZWxlY3QgKDEwMDBiYXNlVCA8ZnVsbC1kdXBs ZXg+KQpzdGF0dXM6IGFjdGl2ZQoKVGhlbiBJIGRpZCBpcGVyZiB0ZXN0IHdpdGggVURQLiBQbGVh c2UsIHRlbGwgbWUgaWYgwqB0aGlzIGlzIG5vcm1hbC4gQXQgdGhlIG1vbWVudCBJIGRvbid0IGtu b3cgYW55IHJlYXNvbiBmb3IgVURQIHRvIGJlIHNvIHNsb29vdy4KI2lwZXJmIC1zIC11Ci0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpT ZXJ2ZXIgbGlzdGVuaW5nIG9uIFVEUCBwb3J0IDUwMDEKUmVjZWl2aW5nIDE0NzAgYnl0ZSBkYXRh Z3JhbXMKVURQIGJ1ZmZlciBzaXplOiA0MS4xIEtCeXRlIChkZWZhdWx0KQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KWyAgM10gbG9j YWwgMTkyLjE2OC4wLjEgcG9ydCA1MDAxIGNvbm5lY3RlZCB3aXRoIDE5Mi4xNjguMC42IHBvcnQg MzUwNApbIElEXSBJbnRlcnZhbCAgICAgICBUcmFuc2ZlciAgICAgQmFuZHdpZHRoICAgICAgICBK aXR0ZXIgICBMb3N0L1RvdGFsIERhdGFncmFtcwpbICAzXSAgMC4wLTEwLjAgc2VjICAxLjI1IE1C eXRlcyAgMS4wNSBNYml0cy9zZWMgICAxLjExMiBtcyAgICAwLyAgODkyICgwJSkKWyAgM10gIDAu MC0xMC4wIHNlYyAgMSBkYXRhZ3JhbXMgcmVjZWl2ZWQgb3V0LW9mLW9yZGVyCgotLcKgCkJlc3Qg cmVnYXJkcywKS29uc3RhbnRpbiBLdXp2ZXNvdgo= From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 10:19:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8FF9BCFF for ; Tue, 8 Oct 2013 10:19:17 +0000 (UTC) (envelope-from kuzvesov@list.ru) Received: from fallback5.mail.ru (fallback5.mail.ru [94.100.176.59]) by mx1.freebsd.org (Postfix) with ESMTP id A36A225D5 for ; Tue, 8 Oct 2013 10:19:16 +0000 (UTC) Received: from f404.i.mail.ru (f404.i.mail.ru [185.5.136.75]) by fallback5.mail.ru (mPOP.Fallback_MX) with ESMTP id BC4D8FA55190 for ; Tue, 8 Oct 2013 14:19:13 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=list.ru; s=mail; h=References:Content-Type:Message-ID:Reply-To:Date:Mime-Version:Subject:Cc:To:From; bh=0HH0/4n0M0YLQSRCpLP/wEzMyU9S0ryHLP33wCJP+xY=; b=gnNVytzaftIdab/6u1GL3l/yX7XSAmvgO1+ky1zhctVmgJo1lSRrTfSt2DfBz5ce3fdTYlzn7iWIiMQdhNcyf3aFL32wtAVMMNH+puti1Q8FKogonmowPb03/MU+rzqOaeB0EB7pD2WUjxgRs8rkj9h7fcKzwf6HYW0BDfvRW98=; Received: from mail by f404.i.mail.ru with local (envelope-from ) id 1VTUNc-0005vb-Tf; Tue, 08 Oct 2013 14:19:05 +0400 Received: from [178.169.40.77] by e.mail.ru with HTTP; Tue, 08 Oct 2013 14:19:04 +0400 From: =?UTF-8?B?S29uc3RhbnRpbiBLdXp2ZXNvdg==?= To: =?UTF-8?B?S2V2aW4gT2Jlcm1hbg==?= Subject: =?UTF-8?B?UmVbNV06IEFzc3ltZXRyaWMgTklDIHBlcmZvcm1hbmNlIHByb2JsZW0=?= Mime-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [178.169.40.77] Date: Tue, 08 Oct 2013 14:19:04 +0400 X-Priority: 3 (Normal) Message-ID: <1381227544.227894604@f404.i.mail.ru> X-Mras: Ok X-Spam: undefined References: <1381160691.954872513@f116.i.mail.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?UTF-8?B?ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc=?= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?UTF-8?B?S29uc3RhbnRpbiBLdXp2ZXNvdg==?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 10:19:17 -0000 Ck9uIE1vbiwgIE9jdCA3LCAyMDEzIGF0IDE2OjU3IC0wNzowMCwgS2V2aW4gT2Jlcm1hbiA8cmtv YmVybWFuQGdtYWlsLmNvbT4gd3JvdGU6Cj5PbiBNb24sIE9jdCA3LCAyMDEzIGF0IDg6NDQgQU0s IEtvbnN0YW50aW4gS3V6dmVzb3YgIDwga3V6dmVzb3ZAbGlzdC5ydSA+IHdyb3RlOgo+Pgo+Pkkn dmUgZ290IGEgRnJlZUJTRCBmaWxlIHNlcnZlciBydW5uaW5nIFNhbWJhLCBmaWxlIHVwbG9hZCBz cGVlZHMgYXJlIG9rYXksIGJ1dCBkb3dubG9hZHMgYXJlIHRvbyBzbG93Lgo+PkZpcnN0LCBJIGRl Y2lkZWQgaXQgaXMgU2FtYmEncyBmYXVsdCwgYnV0IHRoZW4gSSByYW4gaXBlcmYgdGVzdHMuLi4K Pj4KPj5PbiBhIHdpbmRvd3MgbWFjaGluZSB3aXRoIGdpZ2FiaXQgTklDOgo+Plo6XGlwZXJmPmlw ZXJmIC1jIDE5Mi4xNjguMC4xCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4+Q2xpZW50IGNvbm5lY3RpbmcgdG8gMTkyLjE2OC4w LjEsIFRDUCBwb3J0IDUwMDEKPj5UQ1Agd2luZG93IHNpemU6IDY0LjAgS0J5dGUgKGRlZmF1bHQp Cj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCj4+WyDCoDNdIGxvY2FsIDE5Mi4xNjguMC4yIHBvcnQgMTA2NCBjb25uZWN0ZWQgd2l0 aCAxOTIuMTY4LjAuMSBwb3J0IDUwMDEKPj5bIElEXSBJbnRlcnZhbCDCoCDCoCDCoCBUcmFuc2Zl ciDCoCDCoCBCYW5kd2lkdGgKPj5bIMKgM10gwqAwLjAtMTAuMiBzZWMgwqAxMi40IE1CeXRlcyDC oDEwLjIgTWJpdHMvc2VjCj4+Cj4+WjpcaXBlcmY+aXBlcmYgLXMKPj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj5TZXJ2ZXIgbGlz dGVuaW5nIG9uIFRDUCBwb3J0IDUwMDEKPj5UQ1Agd2luZG93IHNpemU6IDY0LjAgS0J5dGUgKGRl ZmF1bHQpCj4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCj4+WyDCoDRdIGxvY2FsIDE5Mi4xNjguMC4yIHBvcnQgNTAwMSBjb25uZWN0 ZWQgd2l0aCAxOTIuMTY4LjAuMSBwb3J0IDQxMjIwCj4+WyBJRF0gSW50ZXJ2YWwgwqAgwqAgwqAg VHJhbnNmZXIgwqAgwqAgQmFuZHdpZHRoCj4+WyDCoDRdIMKgMC4wLTEwLjAgc2VjIMKgIDcxNiBN Qnl0ZXMgwqAgNjAwIE1iaXRzL3NlYwo+Pgo+PkFuZCBvbiBhIGFub3RoZXIgd2l0aCBGYXN0RXRo ZXJuZXQgTklDOgo+PkM6XGlwZXJmPmlwZXJmLmV4ZSAtYyAxOTIuMTY4LjAuMQo+Pi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+PkNs aWVudCBjb25uZWN0aW5nIHRvIDE5Mi4xNjguMC4xLCBUQ1AgcG9ydCA1MDAxCj4+VENQIHdpbmRv dyBzaXplOiA2NC4wIEtCeXRlIChkZWZhdWx0KQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+PlsgwqAzXSBsb2NhbCAxOTIuMTY4 LjAuNSBwb3J0IDQ3NTYgY29ubmVjdGVkIHdpdGggMTkyLjE2OC4wLjEgcG9ydCA1MDAxCj4+WyBJ RF0gSW50ZXJ2YWwgwqAgwqAgwqAgVHJhbnNmZXIgwqAgwqAgQmFuZHdpZHRoCj4+WyDCoDNdIMKg MC4wLTEwLjEgc2VjIMKgMTEuNCBNQnl0ZXMgwqA5LjQyIE1iaXRzL3NlYwo+Pgo+PkM6XGlwZXJm PmlwZXJmLmV4ZSAtcwo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQo+PlNlcnZlciBsaXN0ZW5pbmcgb24gVENQIHBvcnQgNTAwMQo+ PlRDUCB3aW5kb3cgc2l6ZTogNjQuMCBLQnl0ZSAoZGVmYXVsdCkKPj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj5bIMKgNF0gbG9j YWwgMTkyLjE2OC4wLjUgcG9ydCA1MDAxIGNvbm5lY3RlZCB3aXRoIDE5Mi4xNjguMC4xIHBvcnQg MTg1NTgKPj5bIElEXSBJbnRlcnZhbCDCoCDCoCDCoCBUcmFuc2ZlciDCoCDCoCBCYW5kd2lkdGgK Pj5bIMKgNF0gwqAwLjAtMTAuMCBzZWMgwqAgMTA2IE1CeXRlcyDCoDg4LjUgTWJpdHMvc2VjCj4+ Cj4+Qm90aCB0ZXN0cyBzaG93IHNlcnZlcidzIE5JQyBwZXJmb3JtYW5jZSBkZWdyYWRhdGlvbiB0 byBhcm91bmQgMTBNYml0L3Mgd2hlbiB0cmFmZmljIGdvZXMgZnJvbSBzZXJ2ZXIgdG8gY2xpZW50 LiBBbmQgZXZlcnl0aGluZyB3b3JrcyBmaW5lIGluIG90aGVyIGRpcmVjdGlvbi4KPj4KPj5JIHZl cmlmaWVkIHRoZSBjYWJsZXMgYW5kIGh1YiBieSBzaW1wbHkgY29ubmVjdGluZyBzZXJ2ZXIgYW5k IGEgdGVzdCBtYWNoaW5lIHdpdGggYSBuZXcgc2hvcnQgcGF0Y2ggY29yZC4gSSB0cmllZCB0byBj aGFuZ2Ugc2VydmVyJ3MgTklDIGZyb20gRC1MaW5rIERHRS01MjhUIHRvIFBsYW5ldCBFTlctOTYw NC4gQW5kIGl0IGJlY2FtZSBldmVuIHdvcnNlIC0KPj7CoHVzaW5nIFBsYW5ldCBOSUMKPj7CoHNw ZWVkcyBzbG93ZWQgZG93biB0byBhcm91bmQgNTAwTWJpdC9zIHRvIHNlcnZlciBhbmQgdGhlIHNh bWUgMTBNYml0L3MgdG8gY2xpZW50LiBJIHRyaWVkIHRvIGNoYW5nZSBOSUMncyBtZWRpYSB0byAx MDBCYXNlVFgsIGl0IGRpZG4ndCBoZWxwIHRvby4gV2hhdCBlbHNlIHNob3VsZCBJIHRyeSB0byBm aXggdGhlIHByb2JsZW0/IE1heWJlIG15IHN5c3RlbSByZXF1aXJlcyBpcyBqdXN0IG1pc2NvbmZp Z3VyZWQ/Cj4+Cj4+U3lzdGVtIGNvbmZpZ3VyYXRpb246Cj4+T1M6IEZyZWVCU0QgOS4yLXJlbGVh c2UKPj5LZXJuZWw6IGdlbmVyaWMKPj5GaXJld2FsbDogbm9uZQo+Pi9ib290L2xvYWRlci5jb25m IC0gbG9hZCB6ZnMgbW9kdWxlcyBvbmx5Cj4+L2V0Yy9zeXNjdGwuY29uZiAtIGVtcHR5Cj4+TklD OiBELUxpbmsgREdFLTUyOFQgLyBQbGFuZXQgRU5XLTk2MDQKPj4KPj4tLQo+PktvbnN0YW50aW4g S3V6dmVzb3YKPsKgCj5PdXRwdXQgZnJvbSBpZmNvbmZpZyB3b3VsZCBwcm9iYWJseSBiZSBoZWxw ZnVsLCBidXQgSSdkIGFsc28gCnN1Z2dlc3QgdGhhdCB5b3UgY2FwdHVyZSBwYWNrZXRzIChvciwg YXQgbGVhc3QgaGVhZGVycykgZm9yIGF0IGxlYXN0IHRoZQogc3RhcnQgb2YgdGhlIHRyYW5zZmVy IGFuZCBsb29rIGF0IHRoZW0gd2l0aCB3aXJlc2hhcmsgb3Igc29tZSBzaW1pbGFyIAp0b29sLiAK Pgo+d2lyZXNoYXJrIGNhbiB0ZWxsIHlvdSBxdWl0ZSBhIGJpdCBhbmQsIGlmIHlvdSBmZWVkIHRo ZSAKY2FwdHVyZSBpbnRvIHRjcHRyYWNlLCB5b3UgY2FuIHJlYWxseSBzZWUgd2hhdCBpcyBoYXBw ZW5pbmcuIChOb3RlLCAKd2lyZXNoYXJrIHByb3ZpZGVzIGluZGljYXRpb25zIG9mIHByb2JsZW1z IHRoYXQgY2FuIG1ha2Ugc2Vuc2UgdG8gcGVvcGxlCiBub3QgY29udmVyc2FudCB3aXRoIHRoZSBn b3J5IGRldGFpbHMgb2YgVENQLCB0aG91Z2ggc29tZSBpc3N1ZXMgbWF5IG5vdCAKYmUgb2J2aW91 cy4gdGNwdHJhY2Ugb3V0cHV0IGNhbiBiZSB1dHRlcmx5IGNyeXB0aWMgaWYgeW91IGRvbid0IAp1 bmRlcnN0YW5kIGEgbG90IG9mIHRoZSBkZXRhaWxzIG9mIFRDUCBhbmQgY29uZ2VzdGlvbiBjb250 cm9sLgo+Cj5Cb3RoCiB3aXJlc2hhcmsgYW5kIHRjcHRyYWNlIGFyZSBpbiBwb3J0cyBhbmQgYXJl IGJlc3QgaW5zdGFsbGVkIG9uIGEgCndvcmtzdGF0aW9uLiBUaGUgdGNwZHVtcCBvdXRwdXQgY2Fu IGJlIHVzZWQgYXMgaW5wdXQgdG8gYm90aC4gKCJ0Y3BkdW1wIAotcHcgRklMRSAtaSBJTlRFUkZB Q0UgaG9zdCBBRERSRVNTIiBjYW4gZG8gdGhlIGpvYi4gVGhlbiBjb3B5IHRoZSAKY2FwdHVyZSB0 byB0aGUgcmlnaHQgcGxhY2UgZm9yIGFuYWx5c2lzLiBCdXQgc3RhcnQgd2l0aCBjb25maWd1cmF0 aW9uIAphbmQgY291bnRlcnMgZm9yIHRoZSBpbnRlcmZhY2UgKG5ldHN0YXQgLWkpLgo+LS0gCj5S LiBLZXZpbiBPYmVybWFuLCBOZXR3b3JrIEVuZ2luZWVyCj5FLW1haWw6ICBya29iZXJtYW5AZ21h aWwuY29tCgpTb3JyeSwgSSBkaWRuJ3Qga25vdyB0aGF0IFVEUCBiYW5kd2lkdGggbXVzdCBiZSBz cGVjaWZpZWQgbWFudWFsbHksIG90aGVyd2lzZSBpdCBkZWZhdWx0cyB0byAxLjBNYml0L3MuCk5l dyBVRFAgdGVzdHMgc2hvdyB0aGF0IHRoZXJlIG11c3QgYmUgc29tZSBUQ1AgbWlzY29uZmlndXJh dGlvbjoKCiNpcGVyZiAtcyAtdQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KU2VydmVyIGxpc3RlbmluZyBvbiBVRFAgcG9ydCA1MDAx ClJlY2VpdmluZyAxNDcwIGJ5dGUgZGF0YWdyYW1zClVEUCBidWZmZXIgc2l6ZTogNDEuMSBLQnl0 ZSAoZGVmYXVsdCkKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tClsgIDNdIGxvY2FsIDE5Mi4xNjguMC4xIHBvcnQgNTAwMSBjb25uZWN0 ZWQgd2l0aCAxOTIuMTY4LjAuMiBwb3J0IDEwMzkKWyBJRF0gSW50ZXJ2YWwgICAgICAgVHJhbnNm ZXIgICAgIEJhbmR3aWR0aCAgICAgICAgSml0dGVyICAgTG9zdC9Ub3RhbCBEYXRhZ3JhbXMKWyAg M10gIDAuMC0xMC4wIHNlYyAgIDYyNiBNQnl0ZXMgICA1MjUgTWJpdHMvc2VjICAgMC4wNjIgbXMg MTMxODEvNDU5OTk1ICgyLjklKQpbICAzXSAgMC4wLTEwLjAgc2VjICAxIGRhdGFncmFtcyByZWNl aXZlZCBvdXQtb2Ytb3JkZXIKCiNpcGVyZiAtYyAxOTIuMTY4LjAuMiAtdSAtYiAxMDAwTQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K Q2xpZW50IGNvbm5lY3RpbmcgdG8gMTkyLjE2OC4wLjIsIFVEUCBwb3J0IDUwMDEKU2VuZGluZyAx NDcwIGJ5dGUgZGF0YWdyYW1zClVEUCBidWZmZXIgc2l6ZTogOS4wMCBLQnl0ZSAoZGVmYXVsdCkK LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tClsgIDNdIGxvY2FsIDE5Mi4xNjguMC4xIHBvcnQgMTUzNDcgY29ubmVjdGVkIHdpdGggMTky LjE2OC4wLjIgcG9ydCA1MDAxClsgSURdIEludGVydmFsICAgICAgIFRyYW5zZmVyICAgICBCYW5k d2lkdGgKWyAgM10gIDAuMC0xMC4wIHNlYyAgIDg4MiBNQnl0ZXMgICA3NDAgTWJpdHMvc2VjClsg IDNdIFNlbnQgNjMyNjczIGRhdGFncmFtcwpbICAzXSBXQVJOSU5HOiBkaWQgbm90IHJlY2VpdmUg YWNrIG9mIGxhc3QgZGF0YWdyYW0gYWZ0ZXIgMTAgdHJpZXMuCgpUaGUgb25seSBwcm9ibGVtIHdp cmVzaGFyayBzaG93ZWQgdG8gbWUgaXMgd3JvbmcgSVAgaGVhZGVyIGNoZWNrc3VtcyBpbiBwYWNr ZXRzIG9yaWdpbmF0ZWQgZnJvbSBzZXJ2ZXIuCgotLSAKS29uc3RhbnRpbiBLdXp2ZXNvdgo= From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 14:15:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DF92B3AE for ; Tue, 8 Oct 2013 14:15:12 +0000 (UTC) (envelope-from glebius@FreeBSD.org) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B0062651 for ; Tue, 8 Oct 2013 14:15:11 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r98EF4bQ023253; Tue, 8 Oct 2013 18:15:04 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r98EF4jC023252; Tue, 8 Oct 2013 18:15:04 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 8 Oct 2013 18:15:04 +0400 From: Gleb Smirnoff To: Eric van Gyzen Subject: Re: sys/net/radix.h: #define Free(p) for user-land Message-ID: <20131008141504.GA22563@FreeBSD.org> References: <5252D7F7.3030709@dell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5252D7F7.3030709@dell.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org, Eric van Gyzen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 14:15:12 -0000 Eric, On Mon, Oct 07, 2013 at 10:49:11AM -0500, Eric van Gyzen wrote: E> The user-land definition of the Free() macro in sys/net/radix.h is E> rather inconvenient. I work on a large C++ code-base, where several E> classes define Free() functions. This header file gets indirectly E> included in a few modules (via nested #includes), so we have to #undef E> Free to work around this macro definition. E> E> Ideally, radix.h would define a more unique name, such as R_Free(). If E> I were using a C code-base, you could say the same about my code, but E> it's C++, and Free() is already well qualified by classes and/or namespaces. E> E> Is this Free() macro considered a well-defined, widely known, and E> therefore mandatory part of the API, or could it be renamed to something E> more unique? Alternatively, could it be changed to an inline function E> definition, so as not to conflict with declarations in other E> namespaces? If any of these is possible, I'll gladly provide the E> blindingly trivial patch, although I don't have a commit bit. E> E> Finding in-tree consumers of this macro is difficult, due to its generic E> name. Its counterparts--R_Malloc and R_Zalloc--only appear in E> sys/net/{radix,route,rtsock}.c (on head). The recent ipfilter update E> removed the only [potential] in-tree user-land consumer. The easiest way to find consumers would be to build test the trivial patch :) -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 14:47:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E1BD9C46; Tue, 8 Oct 2013 14:47:34 +0000 (UTC) (envelope-from Eric_Van_Gyzen@dell.com) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 995FD2829; Tue, 8 Oct 2013 14:47:34 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.90,1056,1371099600"; d="scan'208";a="47967551" Message-ID: <52541ABF.70101@dell.com> Date: Tue, 8 Oct 2013 09:46:23 -0500 From: Eric van Gyzen Organization: Dell, Inc. User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130702 Thunderbird/17.0.7 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: sys/net/radix.h: #define Free(p) for user-land References: <5252D7F7.3030709@dell.com> <20131008141504.GA22563@FreeBSD.org> In-Reply-To: <20131008141504.GA22563@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Eric van Gyzen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 14:47:35 -0000 On 10/08/2013 09:15, Gleb Smirnoff wrote: > On Mon, Oct 07, 2013 at 10:49:11AM -0500, Eric van Gyzen wrote: > E> The user-land definition of the Free() macro in sys/net/radix.h is > E> rather inconvenient. I work on a large C++ code-base, where several > E> classes define Free() functions. This header file gets indirectly > E> included in a few modules (via nested #includes), so we have to #undef > E> Free to work around this macro definition. > E> > E> Ideally, radix.h would define a more unique name, such as R_Free(). If > E> I were using a C code-base, you could say the same about my code, but > E> it's C++, and Free() is already well qualified by classes and/or namespaces. > E> > E> Is this Free() macro considered a well-defined, widely known, and > E> therefore mandatory part of the API, or could it be renamed to something > E> more unique? Alternatively, could it be changed to an inline function > E> definition, so as not to conflict with declarations in other > E> namespaces? If any of these is possible, I'll gladly provide the > E> blindingly trivial patch, although I don't have a commit bit. > E> > E> Finding in-tree consumers of this macro is difficult, due to its generic > E> name. Its counterparts--R_Malloc and R_Zalloc--only appear in > E> sys/net/{radix,route,rtsock}.c (on head). The recent ipfilter update > E> removed the only [potential] in-tree user-land consumer. > > The easiest way to find consumers would be to build test the trivial patch :) Gleb, So true. :) Before I bothered, I just wanted to ask if a change was impractical due to API commitments with several known out-of-tree consumers. Hearing no such replies, I'll test a patch. Eric From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 18:06:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4FED9835; Tue, 8 Oct 2013 18:06:12 +0000 (UTC) (envelope-from Eric_Van_Gyzen@dell.com) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D92642529; Tue, 8 Oct 2013 18:06:11 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.90,1057,1371099600"; d="scan'208";a="55268139" Message-ID: <5254495E.3050206@dell.com> Date: Tue, 8 Oct 2013 13:05:18 -0500 From: Eric van Gyzen Organization: Dell, Inc. User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130702 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: sys/net/radix.h: #define Free(p) for user-land References: <5252D7F7.3030709@dell.com> <20131008141504.GA22563@FreeBSD.org> <52541ABF.70101@dell.com> In-Reply-To: <52541ABF.70101@dell.com> Content-Type: multipart/mixed; boundary="------------050603050800010005040000" Cc: Eric van Gyzen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:06:12 -0000 --------------050603050800010005040000 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 10/08/2013 09:46, Eric van Gyzen wrote: > On 10/08/2013 09:15, Gleb Smirnoff wrote: >> On Mon, Oct 07, 2013 at 10:49:11AM -0500, Eric van Gyzen wrote: >> E> The user-land definition of the Free() macro in sys/net/radix.h is >> E> rather inconvenient. I work on a large C++ code-base, where several >> E> classes define Free() functions. This header file gets indirectly >> E> included in a few modules (via nested #includes), so we have to #undef >> E> Free to work around this macro definition. >> E> >> E> Ideally, radix.h would define a more unique name, such as R_Free(). If >> E> I were using a C code-base, you could say the same about my code, but >> E> it's C++, and Free() is already well qualified by classes and/or namespaces. >> E> >> E> Is this Free() macro considered a well-defined, widely known, and >> E> therefore mandatory part of the API, or could it be renamed to something >> E> more unique? Alternatively, could it be changed to an inline function >> E> definition, so as not to conflict with declarations in other >> E> namespaces? If any of these is possible, I'll gladly provide the >> E> blindingly trivial patch, although I don't have a commit bit. >> E> >> E> Finding in-tree consumers of this macro is difficult, due to its generic >> E> name. Its counterparts--R_Malloc and R_Zalloc--only appear in >> E> sys/net/{radix,route,rtsock}.c (on head). The recent ipfilter update >> E> removed the only [potential] in-tree user-land consumer. >> >> The easiest way to find consumers would be to build test the trivial patch :) > Gleb, > > So true. :) Before I bothered, I just wanted to ask if a change was > impractical due to API commitments with several known out-of-tree > consumers. Hearing no such replies, I'll test a patch. I simply renamed Free to R_Free, and buildworld succeeded. I built head r256133 on amd64 with no make.conf or src.conf. So, there are [probably] no in-tree consumers. The question then becomes, do we need these user-land definitions at all? Eric --------------050603050800010005040000 Content-Type: text/plain; charset="ISO-8859-1"; name="radix.h.Free.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="radix.h.Free.patch" diff --git a/sys/net/radix.h b/sys/net/radix.h index 5bacaa3..1c8d654 100644 --- a/sys/net/radix.h +++ b/sys/net/radix.h @@ -141,7 +141,7 @@ struct radix_node_head { #ifndef _KERNEL #define R_Malloc(p, t, n) (p = (t) malloc((unsigned int)(n))) #define R_Zalloc(p, t, n) (p = (t) calloc(1,(unsigned int)(n))) -#define Free(p) free((char *)p); +#define R_Free(p) free((char *)p); #else #define R_Malloc(p, t, n) (p = (t) malloc((unsigned long)(n), M_RTABLE, M_NOWAIT)) #define R_Zalloc(p, t, n) (p = (t) malloc((unsigned long)(n), M_RTABLE, M_NOWAIT | M_ZERO)) --------------050603050800010005040000-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 18:20:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 56C31FCA for ; Tue, 8 Oct 2013 18:20:09 +0000 (UTC) (envelope-from glebius@FreeBSD.org) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D3C1C2657 for ; Tue, 8 Oct 2013 18:20:08 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r98IJvjs024238; Tue, 8 Oct 2013 22:19:57 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r98IJuaY024237; Tue, 8 Oct 2013 22:19:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 8 Oct 2013 22:19:56 +0400 From: Gleb Smirnoff To: Eric van Gyzen Subject: Re: sys/net/radix.h: #define Free(p) for user-land Message-ID: <20131008181956.GD22563@glebius.int.ru> References: <5252D7F7.3030709@dell.com> <20131008141504.GA22563@FreeBSD.org> <52541ABF.70101@dell.com> <5254495E.3050206@dell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5254495E.3050206@dell.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org, Eric van Gyzen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:20:09 -0000 Eric, On Tue, Oct 08, 2013 at 01:05:18PM -0500, Eric van Gyzen wrote: E> > So true. :) Before I bothered, I just wanted to ask if a change was E> > impractical due to API commitments with several known out-of-tree E> > consumers. Hearing no such replies, I'll test a patch. E> E> I simply renamed Free to R_Free, and buildworld succeeded. I built head E> r256133 on amd64 with no make.conf or src.conf. E> E> So, there are [probably] no in-tree consumers. The question then E> becomes, do we need these user-land definitions at all? I suppose we'd better have. The radix code was designed so that it could be tested in userland. Probably it isn't compilable nowadays, but R_Free() won't hurt anyone. I'd appreciate if you run universe build for this change. We are in release cycle now and any build breakage can hurt release process. If universe succeeds, we can check it in. E> diff --git a/sys/net/radix.h b/sys/net/radix.h E> index 5bacaa3..1c8d654 100644 E> --- a/sys/net/radix.h E> +++ b/sys/net/radix.h E> @@ -141,7 +141,7 @@ struct radix_node_head { E> #ifndef _KERNEL E> #define R_Malloc(p, t, n) (p = (t) malloc((unsigned int)(n))) E> #define R_Zalloc(p, t, n) (p = (t) calloc(1,(unsigned int)(n))) E> -#define Free(p) free((char *)p); E> +#define R_Free(p) free((char *)p); E> #else E> #define R_Malloc(p, t, n) (p = (t) malloc((unsigned long)(n), M_RTABLE, M_NOWAIT)) E> #define R_Zalloc(p, t, n) (p = (t) malloc((unsigned long)(n), M_RTABLE, M_NOWAIT | M_ZERO)) -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 18:46:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 286DD853 for ; Tue, 8 Oct 2013 18:46:12 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id DF81F27BF for ; Tue, 8 Oct 2013 18:46:11 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 705A57300A; Tue, 8 Oct 2013 20:47:52 +0200 (CEST) Date: Tue, 8 Oct 2013 20:47:52 +0200 From: Luigi Rizzo To: Eric van Gyzen Subject: Re: sys/net/radix.h: #define Free(p) for user-land Message-ID: <20131008184752.GA97567@onelab2.iet.unipi.it> References: <5252D7F7.3030709@dell.com> <20131008141504.GA22563@FreeBSD.org> <52541ABF.70101@dell.com> <5254495E.3050206@dell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5254495E.3050206@dell.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, Eric van Gyzen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:46:12 -0000 On Tue, Oct 08, 2013 at 01:05:18PM -0500, Eric van Gyzen wrote: > On 10/08/2013 09:46, Eric van Gyzen wrote: > > On 10/08/2013 09:15, Gleb Smirnoff wrote: > >> On Mon, Oct 07, 2013 at 10:49:11AM -0500, Eric van Gyzen wrote: ... > >> The easiest way to find consumers would be to build test the trivial patch :) > > Gleb, > > > > So true. :) Before I bothered, I just wanted to ask if a change was > > impractical due to API commitments with several known out-of-tree > > consumers. Hearing no such replies, I'll test a patch. > > I simply renamed Free to R_Free, and buildworld succeeded. I built head > r256133 on amd64 with no make.conf or src.conf. > > So, there are [probably] no in-tree consumers. The question then > becomes, do we need these user-land definitions at all? I am pretty sure there are no in-tree consumers, but for the time being please do keep the userland definitions since they are already there. In general it is useful to be able to compile kernel code in userland for functional and performance testing. One could argue that the wrappers could be implemented in a more generic way, but it will probably take a while (or forever) before we get there... cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Oct 8 18:48:35 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41EE6AB4; Tue, 8 Oct 2013 18:48:35 +0000 (UTC) (envelope-from Eric_Van_Gyzen@dell.com) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E7FC327DB; Tue, 8 Oct 2013 18:48:33 +0000 (UTC) X-Loopcount0: from 64.238.244.148 X-IronPort-AV: E=Sophos;i="4.90,1058,1371099600"; d="scan'208";a="55290732" Message-ID: <5254537F.2070309@dell.com> Date: Tue, 8 Oct 2013 13:48:31 -0500 From: Eric van Gyzen Organization: Dell, Inc. User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130702 Thunderbird/17.0.7 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: sys/net/radix.h: #define Free(p) for user-land References: <5252D7F7.3030709@dell.com> <20131008141504.GA22563@FreeBSD.org> <52541ABF.70101@dell.com> <5254495E.3050206@dell.com> <20131008181956.GD22563@glebius.int.ru> In-Reply-To: <20131008181956.GD22563@glebius.int.ru> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Eric van Gyzen X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:48:35 -0000 On 10/08/2013 13:19, Gleb Smirnoff wrote: > On Tue, Oct 08, 2013 at 01:05:18PM -0500, Eric van Gyzen wrote: > E> > So true. :) Before I bothered, I just wanted to ask if a change was > E> > impractical due to API commitments with several known out-of-tree > E> > consumers. Hearing no such replies, I'll test a patch. > E> > E> I simply renamed Free to R_Free, and buildworld succeeded. I built head > E> r256133 on amd64 with no make.conf or src.conf. > E> > E> So, there are [probably] no in-tree consumers. The question then > E> becomes, do we need these user-land definitions at all? > > I suppose we'd better have. The radix code was designed so that it > could be tested in userland. Probably it isn't compilable nowadays, > but R_Free() won't hurt anyone. > > I'd appreciate if you run universe build for this change. We are > in release cycle now and any build breakage can hurt release process. Gleb, It's running now. Thanks for your help. By the way, how much disk space does a "make universe" need nowadays? > If universe succeeds, we can check it in. > > E> diff --git a/sys/net/radix.h b/sys/net/radix.h > E> index 5bacaa3..1c8d654 100644 > E> --- a/sys/net/radix.h > E> +++ b/sys/net/radix.h > E> @@ -141,7 +141,7 @@ struct radix_node_head { > E> #ifndef _KERNEL > E> #define R_Malloc(p, t, n) (p = (t) malloc((unsigned int)(n))) > E> #define R_Zalloc(p, t, n) (p = (t) calloc(1,(unsigned int)(n))) > E> -#define Free(p) free((char *)p); > E> +#define R_Free(p) free((char *)p); > E> #else > E> #define R_Malloc(p, t, n) (p = (t) malloc((unsigned long)(n), M_RTABLE, M_NOWAIT)) > E> #define R_Zalloc(p, t, n) (p = (t) malloc((unsigned long)(n), M_RTABLE, M_NOWAIT | M_ZERO)) > > From owner-freebsd-net@FreeBSD.ORG Wed Oct 9 03:35:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 07754DF9; Wed, 9 Oct 2013 03:35:01 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CFD572611; Wed, 9 Oct 2013 03:35:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r993Z0dN095389; Wed, 9 Oct 2013 03:35:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r993Z0ZT095388; Wed, 9 Oct 2013 03:35:00 GMT (envelope-from linimon) Date: Wed, 9 Oct 2013 03:35:00 GMT Message-Id: <201310090335.r993Z0ZT095388@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/182847: [netinet6] [patch] Remove dead code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 03:35:01 -0000 Old Synopsis: Remove dead code New Synopsis: [netinet6] [patch] Remove dead code Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Oct 9 03:34:41 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=182847 From owner-freebsd-net@FreeBSD.ORG Wed Oct 9 17:23:29 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1B376A80; Wed, 9 Oct 2013 17:23:29 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88C592725; Wed, 9 Oct 2013 17:23:28 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id c50so583512eek.18 for ; Wed, 09 Oct 2013 10:23:26 -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=rqkZQWzWK3A3NgCElOLQ3R6otOJwg5PL943KQI83G+M=; b=i9CuLAn61/DdxQ5UaRyF+VUwmFInQ/aME6F2A20i39q/9Bwt/btp+w9wH5MNCc/4Mn xlY+Yhg1u/W2UNfwVVYmpW7ollIxLPOcNV2gcjGuUXeiknLzaeKcDDY+cZ7+2BtAD9ye sTBu7LAlhTnys6E8R6cnwuA0Mjzr5Cexq3QB9BUNxeMmBKKXipVIqxjQDUySrfNyPFst xNxMgVtAn1cfsng6wuj+2kz5YdMVtuZHl3lN/OCmFfyPMeQZ4gRvDwujX1byGKsAjVtW AJ3CJlLkq23euLJyxtXtHWb6tPP8XpQCmZDi15jbUkX6yltrrPMuwpiDiESWaKJLVr8O EliA== MIME-Version: 1.0 X-Received: by 10.14.172.133 with SMTP id t5mr12910731eel.35.1381339406867; Wed, 09 Oct 2013 10:23:26 -0700 (PDT) Received: by 10.14.105.137 with HTTP; Wed, 9 Oct 2013 10:23:26 -0700 (PDT) In-Reply-To: <20130928224501.GX41229@kib.kiev.ua> References: <20130928213038.GT41229@kib.kiev.ua> <20130928224501.GX41229@kib.kiev.ua> Date: Wed, 9 Oct 2013 10:23:26 -0700 Message-ID: Subject: Re: igb(4) panic: already enqueue From: hiren panchasara To: Jack F Vogel , Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:23:29 -0000 Jack, I am also seeing similar panics at $work on a couple weeks old STABLE-9. Can you please look into this issue? cheers, Hiren 1) HP DL360e Gen8, 2 x Xeon E5-2430 2.20GHz panic: buf=0xfffffe002810d700 already enqueue at 995 prod=997 cons=995 cpuid = 17 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff868637b030 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff868637b0f0 panic() at panic+0x1d8/frame 0xffffff868637b1f0 igb_mq_start() at igb_mq_start+0x1cb/frame 0xffffff868637b240 ether_output_frame() at ether_output_frame+0x33/frame 0xffffff868637b260 ether_output() at ether_output+0x52d/frame 0xffffff868637b2f0 ip_output() at ip_output+0xe38/frame 0xffffff868637b3e0 tcp_output() at tcp_output+0x122c/frame 0xffffff868637b5a0 tcp_do_segment() at tcp_do_segment+0x306c/frame 0xffffff868637b6c0 tcp_input() at tcp_input+0x909/frame 0xffffff868637b7f0 ip_input() at ip_input+0xbd/frame 0xffffff868637b840 netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xffffff868637b8a0 ether_demux() at ether_demux+0x17d/frame 0xffffff868637b8d0 ether_nh_input() at ether_nh_input+0x208/frame 0xffffff868637b910 netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xffffff868637b970 igb_rxeof() at igb_rxeof+0x394/frame 0xffffff868637b9e0 igb_handle_que() at igb_handle_que+0x9b/frame 0xffffff868637ba20 taskqueue_run_locked() at taskqueue_run_locked+0x93/frame 0xffffff868637ba80 taskqueue_thread_loop() at taskqueue_thread_loop+0x3e/frame 0xffffff868637baa0 fork_exit() at fork_exit+0x135/frame 0xffffff868637baf0 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff868637baf0 2) HP DL160 G6, 2 x Xeon E5620 2.40GHz panic: buf=0xfffffe01b6334700 already enqueue at 42 prod=43 cons=42 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff800037a620 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff800037a6e0 panic() at panic+0x1d8/frame 0xffffff800037a7e0 igb_mq_start() at igb_mq_start+0x1cb/frame 0xffffff800037a830 ether_output_frame() at ether_output_frame+0x33/frame 0xffffff800037a850 ether_output() at ether_output+0x52d/frame 0xffffff800037a8e0 ip_output() at ip_output+0xe38/frame 0xffffff800037a9d0 syncache_respond() at syncache_respond+0x462/frame 0xffffff800037aa90 syncache_timer() at syncache_timer+0xdf/frame 0xffffff800037aac0 softclock() at softclock+0x2c6/frame 0xffffff800037ab60 intr_event_execute_handlers() at intr_event_execute_handlers+0x6a/frame 0xffffff800037ab90 ithread_loop() at ithread_loop+0xac/frame 0xffffff800037abe0 fork_exit() at fork_exit+0x135/frame 0xffffff800037ac30 fork_trampoline() at fork_trampoline+0xe/frame 0xffffff800037ac30 From owner-freebsd-net@FreeBSD.ORG Wed Oct 9 17:56:27 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2DBD39CF; Wed, 9 Oct 2013 17:56:27 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE77A298C; Wed, 9 Oct 2013 17:56:26 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id i3so758386vbh.26 for ; Wed, 09 Oct 2013 10:56:26 -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=5QK5CWpuh7J7NKUojYJYZOgilAqRiCV7LuIqB+Yo+Fg=; b=qJCljoETSdYRiGtkkdA0sGcdC6BqVYbp3JeG+qRfFIbQvKrCPYv/Sz3MsBradis1kO 8THcGzn+ZGBQk5/0guHwPRYtKGM+iUBRHiUgZGeGw8pyHEZkN7pVMdRzh4QCAJST9sej aH03nOudnwa3716WsBFaTs8FXtvPFOZ4xF30QohdKr9iOC+AORSagmmLMDwWhV4M6nWh 51zaguQt5wbDz0zDx+LBqOpBxSYXI//TrRwhi3n5qwmdvhaNsD2zVwfZzn4AjC8bQ+bD 3s/Xza1h7601XN91TE1KE7ND1gTz4vEd6Pjj/YcEh3Z0/0Jvr40pwaMiPHcVFt+oH+kv y5jw== MIME-Version: 1.0 X-Received: by 10.220.199.5 with SMTP id eq5mr6571109vcb.16.1381341386011; Wed, 09 Oct 2013 10:56:26 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Wed, 9 Oct 2013 10:56:25 -0700 (PDT) In-Reply-To: References: <20130928213038.GT41229@kib.kiev.ua> <20130928224501.GX41229@kib.kiev.ua> Date: Wed, 9 Oct 2013 10:56:25 -0700 Message-ID: Subject: Re: igb(4) panic: already enqueue From: Jack Vogel To: hiren panchasara Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jack F Vogel , Konstantin Belousov , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:56:27 -0000 Give the new driver I just committed to HEAD a try to verify/falsify a fix please. Regards, Jack On Wed, Oct 9, 2013 at 10:23 AM, hiren panchasara < hiren.panchasara@gmail.com> wrote: > Jack, > I am also seeing similar panics at $work on a couple weeks old STABLE-9. > > Can you please look into this issue? > > cheers, > Hiren > > 1) HP DL360e Gen8, 2 x Xeon E5-2430 2.20GHz > > panic: buf=0xfffffe002810d700 already enqueue at 995 prod=997 cons=995 > cpuid = 17 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > 0xffffff868637b030 > kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff868637b0f0 > panic() at panic+0x1d8/frame 0xffffff868637b1f0 > igb_mq_start() at igb_mq_start+0x1cb/frame 0xffffff868637b240 > ether_output_frame() at ether_output_frame+0x33/frame 0xffffff868637b260 > ether_output() at ether_output+0x52d/frame 0xffffff868637b2f0 > ip_output() at ip_output+0xe38/frame 0xffffff868637b3e0 > tcp_output() at tcp_output+0x122c/frame 0xffffff868637b5a0 > tcp_do_segment() at tcp_do_segment+0x306c/frame 0xffffff868637b6c0 > tcp_input() at tcp_input+0x909/frame 0xffffff868637b7f0 > ip_input() at ip_input+0xbd/frame 0xffffff868637b840 > netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xffffff868637b8a0 > ether_demux() at ether_demux+0x17d/frame 0xffffff868637b8d0 > ether_nh_input() at ether_nh_input+0x208/frame 0xffffff868637b910 > netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xffffff868637b970 > igb_rxeof() at igb_rxeof+0x394/frame 0xffffff868637b9e0 > igb_handle_que() at igb_handle_que+0x9b/frame 0xffffff868637ba20 > taskqueue_run_locked() at taskqueue_run_locked+0x93/frame > 0xffffff868637ba80 > taskqueue_thread_loop() at taskqueue_thread_loop+0x3e/frame > 0xffffff868637baa0 > fork_exit() at fork_exit+0x135/frame 0xffffff868637baf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff868637baf0 > > 2) HP DL160 G6, 2 x Xeon E5620 2.40GHz > > panic: buf=0xfffffe01b6334700 already enqueue at 42 prod=43 cons=42 > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > 0xffffff800037a620 > kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff800037a6e0 > panic() at panic+0x1d8/frame 0xffffff800037a7e0 > igb_mq_start() at igb_mq_start+0x1cb/frame 0xffffff800037a830 > ether_output_frame() at ether_output_frame+0x33/frame 0xffffff800037a850 > ether_output() at ether_output+0x52d/frame 0xffffff800037a8e0 > ip_output() at ip_output+0xe38/frame 0xffffff800037a9d0 > syncache_respond() at syncache_respond+0x462/frame 0xffffff800037aa90 > syncache_timer() at syncache_timer+0xdf/frame 0xffffff800037aac0 > softclock() at softclock+0x2c6/frame 0xffffff800037ab60 > intr_event_execute_handlers() at > intr_event_execute_handlers+0x6a/frame 0xffffff800037ab90 > ithread_loop() at ithread_loop+0xac/frame 0xffffff800037abe0 > fork_exit() at fork_exit+0x135/frame 0xffffff800037ac30 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff800037ac30 > From owner-freebsd-net@FreeBSD.ORG Wed Oct 9 18:10:04 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7B4C6C5E for ; Wed, 9 Oct 2013 18:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 688812A67 for ; Wed, 9 Oct 2013 18:10:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r99IA3dk098468 for ; Wed, 9 Oct 2013 18:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r99IA3mS098467; Wed, 9 Oct 2013 18:10:03 GMT (envelope-from gnats) Date: Wed, 9 Oct 2013 18:10:03 GMT Message-Id: <201310091810.r99IA3mS098467@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: =?iso-8859-1?Q?Peter_Ankerst=E5l?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 18:10:04 -0000 The following reply was made to PR kern/182665; it has been noted by GNATS. From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= To: bug-followup@FreeBSD.org, peter@pean.org Cc: Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. Date: Wed, 9 Oct 2013 20:08:09 +0200 pciconf -lv ath0@pci0:7:0:0: class=3D0x028000 card=3D0x3114168c = chip=3D0x0030168c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR9300 Wireless LAN adaptor' class =3D network ath1@pci0:13:0:0: class=3D0x028000 card=3D0x30a1168c = chip=3D0x002b168c rev=3D0x01 hdr=3D0x00 vendor =3D 'Atheros Communications Inc.' device =3D 'AR9285 Wireless Network Adapter (PCI-Express)' class =3D network= From owner-freebsd-net@FreeBSD.ORG Wed Oct 9 21:18:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E4BDA7D3 for ; Wed, 9 Oct 2013 21:18:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A576B26B2 for ; Wed, 9 Oct 2013 21:18:02 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id n4so1076639qcx.27 for ; Wed, 09 Oct 2013 14:18:01 -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=h50y2arhBfx81N5AZr61FnFQaI6S0wDkiCtKXyS9ri0=; b=w28rlSSB9YiLtL0E9oaloNxyV5rsFjqITwZU8m8GqBOUG+llKsM8ZHfYwAmofwGe1j bnewqtQSRNUK9CYY7GtBkHmt0UZeXLCC/SG3fqNKz7OkGEjK0IUKaW1QXce8iQNgoRlS 0dE2faSkmXIlrkrhon2vZopiGicV3W77r7G8Y+FnYYJ3v0xxeoLmsyqe4GP+JAs53dKq Y4WZOAe5komS8zn8BnqXWrKsPl/SxyJYJTKKMxw9orY0297WCn4NnV+9RDd5teyxLUDw /cPxC8/cH5Mlv0vVlI0EjLGFxXTqfA0T8m7zlARJMbCjKNirnlYj/ZmG371dQkHWydis x6DQ== MIME-Version: 1.0 X-Received: by 10.229.38.202 with SMTP id c10mr1478947qce.23.1381353481873; Wed, 09 Oct 2013 14:18:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Wed, 9 Oct 2013 14:18:01 -0700 (PDT) In-Reply-To: <201310091810.r99IA3mS098467@freefall.freebsd.org> References: <201310091810.r99IA3mS098467@freefall.freebsd.org> Date: Wed, 9 Oct 2013 14:18:01 -0700 X-Google-Sender-Auth: zi-gSlkl_nja-6Wd6mnU0U9oH7s Message-ID: Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. From: Adrian Chadd To: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 21:18:03 -0000 Hi, Is there a backtrace for this? Iv'e not seen this before. -adrian On 9 October 2013 11:10, Peter Ankerst=E5l wrote: > The following reply was made to PR kern/182665; it has been noted by GNAT= S. > > From: =3D?iso-8859-1?Q?Peter_Ankerst=3DE5l?=3D > To: bug-followup@FreeBSD.org, > peter@pean.org > Cc: > Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlande= v. > Date: Wed, 9 Oct 2013 20:08:09 +0200 > > pciconf -lv > > ath0@pci0:7:0:0: class=3D3D0x028000 card=3D3D0x3114168c =3D > chip=3D3D0x0030168c rev=3D3D0x01 hdr=3D3D0x00 > vendor =3D3D 'Atheros Communications Inc.' > device =3D3D 'AR9300 Wireless LAN adaptor' > class =3D3D network > > ath1@pci0:13:0:0: class=3D3D0x028000 card=3D3D0x30a1168c =3D > chip=3D3D0x002b168c rev=3D3D0x01 hdr=3D3D0x00 > vendor =3D3D 'Atheros Communications Inc.' > device =3D3D 'AR9285 Wireless Network Adapter (PCI-Express)' > class =3D3D network=3D > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Oct 10 00:27:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB1DFE76 for ; Thu, 10 Oct 2013 00:27:57 +0000 (UTC) (envelope-from pkelsey@gmail.com) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52012214F for ; Thu, 10 Oct 2013 00:27:57 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id mx11so684595bkb.32 for ; Wed, 09 Oct 2013 17:27:55 -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=KzeKy5IJ4btaZ9Tebge2Y9qKrsjhyBKhXy5SxiD7FcI=; b=SorxNq1T/dGqq6bI1YlH6N5gNJOAXn8GLkubPFdh4PkQY82XPWjArrgdlCb2mvnYiw S6AW02476UgXLm/YaGEk9AdMsfIE69Nf74Zi/FJqLVoSiLAuzXtadoI6DiLzLMdDhLCK nDHXTeYYxQMFYjbIrxRHnWfJopDPmtpmELT7OT8WcJR53jTegZscKm8q0vaCq4o2RcFf n0qPpDF0JyyfhIrWlHC0w4PynCsabBMXfbQ4oRHZQFAft2WkHyKhXQg7Y02pbe3hcf+M GhAGQ380eI7nR4DXyNqb+Df4R+uPmms7vVipyUo/7uNiZ7dPsYp5YFt0054x02EkRLkr 80JQ== MIME-Version: 1.0 X-Received: by 10.204.69.12 with SMTP id x12mr9489752bki.12.1381364875529; Wed, 09 Oct 2013 17:27:55 -0700 (PDT) Sender: pkelsey@gmail.com Received: by 10.204.232.7 with HTTP; Wed, 9 Oct 2013 17:27:55 -0700 (PDT) Date: Wed, 9 Oct 2013 20:27:55 -0400 X-Google-Sender-Auth: ks-VQWKe5FOxJGm91Nv5T7u2dNQ Message-ID: Subject: [ieee80211] [patch] BPF taps not working for ieee80211 interfaces in monitor mode From: Patrick Kelsey To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=001a1132ec90b640b204e8581211 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 00:27:57 -0000 --001a1132ec90b640b204e8581211 Content-Type: text/plain; charset=ISO-8859-1 Hi, A bug was introduced in r254082 that results in BPF taps never being enabled for ieee80211 interfaces that are in monitor mode. Before r254082, bpf_track() in sys/net80211/ieee80211_freebsd.c was identifying ieee80211 interfaces by checking to see if the value of the ifp->if_start pointer was equal to ieee80211_start. r254082 was a move away from using if_start to using if_transmit in the ieee80211 stack, and bpf_track() was correspondingly updated to check the value of ifp->if_transmit against ieee80211_vap_transmit. The problem is that ifp->if_transmit is set to null_transmit by ieee80211_vap_attach() in sys/net80211/ieee80211.c for interfaces that are in monitor mode (code that has been in place since r195846). One fix that resolves the issue is to use what is likely to be a more stable signature in the check in bpf_track(). A patch against r256155 is attached. -Patrick --001a1132ec90b640b204e8581211 Content-Type: application/octet-stream; name="ieee80211_bpf_track.patch" Content-Disposition: attachment; filename="ieee80211_bpf_track.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hml8uphc0 SW5kZXg6IHN5cy9uZXQ4MDIxMS9pZWVlODAyMTFfZnJlZWJzZC5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5 cy9uZXQ4MDIxMS9pZWVlODAyMTFfZnJlZWJzZC5jCShyZXZpc2lvbiAyNTYxNTUpCisrKyBzeXMv bmV0ODAyMTEvaWVlZTgwMjExX2ZyZWVic2QuYwkod29ya2luZyBjb3B5KQpAQCAtODA4LDkgKzgw OCw5IEBACiBzdGF0aWMgdm9pZAogYnBmX3RyYWNrKHZvaWQgKmFyZywgc3RydWN0IGlmbmV0ICpp ZnAsIGludCBkbHQsIGludCBhdHRhY2gpCiB7Ci0JLyogTkI6IGlkZW50aWZ5IHZhcCdzIGJ5IGlm X3N0YXJ0ICovCisJLyogTkI6IGlkZW50aWZ5IHZhcCdzIGJ5IGlmX2luaXQgKi8KIAlpZiAoZGx0 ID09IERMVF9JRUVFODAyXzExX1JBRElPICYmCi0JICAgIGlmcC0+aWZfdHJhbnNtaXQgPT0gaWVl ZTgwMjExX3ZhcF90cmFuc21pdCkgeworCSAgICBpZnAtPmlmX2luaXQgPT0gaWVlZTgwMjExX2lu aXQpIHsKIAkJc3RydWN0IGllZWU4MDIxMXZhcCAqdmFwID0gaWZwLT5pZl9zb2Z0YzsKIAkJLyoK IAkJICogVHJhY2sgYnBmIHJhZGlvdGFwIGxpc3RlbmVyIHN0YXRlLiAgV2UgbWFyayB0aGUgdmFw Cg== --001a1132ec90b640b204e8581211-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 10 03:22:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3E314D30 for ; Thu, 10 Oct 2013 03:22:46 +0000 (UTC) (envelope-from uv.sudharshan@gmail.com) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1303829A7 for ; Thu, 10 Oct 2013 03:22:46 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id e14so1259223iej.22 for ; Wed, 09 Oct 2013 20:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=nfZJSqs8RaH7d95JkizSoeHjCJtMjNpjL1mdpNHf0FU=; b=jMiP9qEodXFMOuH7yRQfz9sSPYJFG6+qdwF9l2rqFXARVzpAfQ33f/ij2Rjx6b5xFW oYC10s7/z5jRloCjE96xAQAIl0vTNbZWet8b95Qkt0A009w1h6dIv4/GnDISm06fXkTV 4Ia/zYYQZu1KJPb9vPezGN9rz0KeF5GdVJSbtZ2fov4IvMujivxPHNVI3s8fHkono3Nf 2GbyMOA3k94+B1dyrzXeEA/3vL2KMlCUOPeS1tnsaqeROuyjOHS7ZUyIPUIpc+ovseg2 iGUHiP5Whbs6xj1wPQ/FeIcAd3+L0mRxrMIPEecAuK4WZ9gHWM+XsUcoZh3srOqBiaCN WmDg== MIME-Version: 1.0 X-Received: by 10.50.25.129 with SMTP id c1mr4668496igg.23.1381375365392; Wed, 09 Oct 2013 20:22:45 -0700 (PDT) Received: by 10.64.81.16 with HTTP; Wed, 9 Oct 2013 20:22:43 -0700 (PDT) Date: Wed, 9 Oct 2013 23:22:43 -0400 Message-ID: Subject: Traceroute6 with larger datalen fails? From: Sudharshan To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Sudharshan Varada X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 03:22:46 -0000 Hi, Does this look familiar to you? Or Have anyone encountered an error like this with traceroute6? Or Am i missing anything here? Thanks. --- Example --- % traceroute6 fd20:8b1e:b255:800b:250:56ff:fe82:1b09 50 traceroute6 to fd20:8b1e:b255:800b:250:56ff:fe82:1b09 (fd20:8b1e:b255:800b:250:56ff:fe82:1b09) from fd20:8b1e:b255:814e:7e53:4041:1ffa:db52, 64 hops max, 50 byte packets 1 fd20:8b1e:b255:814e::11 1.129 ms 1.132 ms 0.817 ms 2 fd20:8b1e:b255:800b:250:56ff:fe82:1b09 1.314 ms 1.492 ms 0.703 ms % traceroute6 fd20:8b1e:b255:800b:250:56ff:fe82:1b09 60 traceroute6 to fd20:8b1e:b255:800b:250:56ff:fe82:1b09 (fd20:8b1e:b255:800b:250:56ff:fe82:1b09) from fd20:8b1e:b255:814e:7e53:4041:1ffa:db52, 64 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * *^C From owner-freebsd-net@FreeBSD.ORG Thu Oct 10 09:57:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 29EF8DCA for ; Thu, 10 Oct 2013 09:57:12 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BB0342E34 for ; Thu, 10 Oct 2013 09:57:11 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id w62so2199989wes.21 for ; Thu, 10 Oct 2013 02:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=Lt18aA6/xfR5JDwynqQCsZT1V9dOgmLawXGOzdkhXWo=; b=YCaNP7uWUcvWF0FJRWnBy2Y+9rMv75Iym3RDMl+tYWoPbiNIQkXVFELaL1A8v4q28j nh9+55t4z/yLXHS6nYaHE4vTPeDUKHZ9Dkh+olAONywL+96I3v9MFwBLysVwvM0cxv7k ZIeLBRKET+FDhQxXjiNUHvMyhDSxiRyUO+/JsI74dyJXD0iCmnFJWd7NL1IlaXIado8U Ho5nlrQnrq7uCVCYGcXv3DPtTpSnOz4Oi+v3hFU8N3LnCXiyDTMR18t/s6uOM6Sii435 XDHFwc1sTMaJxVybw6lTOfBm5j/y1Xk6Fg1xUyAPj5gkzufz2mCKuEX1bfAkz0aoXVNh w/vQ== X-Received: by 10.180.105.194 with SMTP id go2mr2328330wib.39.1381399030244; Thu, 10 Oct 2013 02:57:10 -0700 (PDT) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.119.73 with HTTP; Thu, 10 Oct 2013 02:56:50 -0700 (PDT) From: h bagade Date: Thu, 10 Oct 2013 13:26:50 +0330 X-Google-Sender-Auth: 4THx0l9S-hFfpCMUrbAvV1XGfSI Message-ID: Subject: igb driver does not support altq To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 09:57:12 -0000 Hi all, I have problem with running altq on igb cards. When trying to run altq on these cards, it outputs an error, driver does not support altq. I have FreeBSD 8.3-stable and tried to fix the problem, after searching in forums, by applying changes made to igb driver through following links: http://svnweb.freebsd.org/base?view=revision&revision=248906 http://svnweb.freebsd.org/base?view=revision&revision=249339 http://lists.freebsd.org/pipermail/svn-src-stable/2013-July/019491.html But it doesn't help and I still have problem with running altq on igb! Does anybody know from which revision the problem is solved? Any hints would be of great help. From owner-freebsd-net@FreeBSD.ORG Thu Oct 10 12:24:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 76E60C7F; Thu, 10 Oct 2013 12:24:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 259BD2765; Thu, 10 Oct 2013 12:24:55 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id b4so1777358qen.6 for ; Thu, 10 Oct 2013 05:24:54 -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=D7sikeDMJD3WMh6NBKd2puEPUvWh6KMSqtcN+810Fcw=; b=A/5naT7kkplFuLwIXXsGI6HtPpXYYZ1hEPIR/ls1dkKxwdpEfLXyNTM84PuaEJuwHe 9A5UqYnLU/Jo9JMl67WyLSJtTcG4v6VB8yjNE1RAYFYcDhkB6a+4RWHIwaBLxjRF5mnf K9dwOzZ9P44uS3vG7mLrrhX/lKaEL+JXxuLWZrFDJdrTgxPnRD0UUxPD0GxyZpJN2ttn Q2J7PnenuiIRtFE7PkMR6RuVs+mwl5iEkl18NZKAofEYCHHq8mJxqeXHeMMOvDiKpsCW ArdcDnR+mZN7aOyJnX0hhtRYzJyeKQc/Nz3LmZ/qqZ2sJWfBStcTttjfNztkZ6nJ+kV+ wvcg== MIME-Version: 1.0 X-Received: by 10.229.38.202 with SMTP id c10mr9634473qce.23.1381407894288; Thu, 10 Oct 2013 05:24:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 10 Oct 2013 05:24:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Oct 2013 05:24:54 -0700 X-Google-Sender-Auth: jtxOSjn7IDnRMVrbPnmtvLSjMac Message-ID: Subject: Re: [ieee80211] [patch] BPF taps not working for ieee80211 interfaces in monitor mode From: Adrian Chadd To: Patrick Kelsey Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , "freebsd-wireless@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 12:24:55 -0000 On 9 October 2013 17:27, Patrick Kelsey wrote: > Hi, > > A bug was introduced in r254082 that results in BPF taps never being > enabled for ieee80211 interfaces that are in monitor mode. > > Before r254082, bpf_track() in sys/net80211/ieee80211_freebsd.c was > identifying ieee80211 interfaces by checking to see if the value of > the ifp->if_start pointer was equal to ieee80211_start. r254082 was a > move away from using if_start to using if_transmit in the ieee80211 > stack, and bpf_track() was correspondingly updated to check the value > of ifp->if_transmit against ieee80211_vap_transmit. The problem is > that ifp->if_transmit is set to null_transmit by > ieee80211_vap_attach() in sys/net80211/ieee80211.c for interfaces that > are in monitor mode (code that has been in place since r195846). > > One fix that resolves the issue is to use what is likely to be a more > stable signature in the check in bpf_track(). > > A patch against r256155 is attached. > Hi! Good catch! Yeah, this is all very dirty code that needs to be ripped out. I'll get this committed ASAP. Thanks! -adrian From owner-freebsd-net@FreeBSD.ORG Thu Oct 10 18:38:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B43DA75C for ; Thu, 10 Oct 2013 18:38:19 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (system.jails.se [91.205.63.85]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F1BB22AE for ; Thu, 10 Oct 2013 18:38:18 +0000 (UTC) Received: from localhost (system.jails.se [91.205.63.85]) by system.jails.se (Postfix) with SMTP id 68FAE18E1AA for ; Thu, 10 Oct 2013 20:38:09 +0200 (CEST) Received: from [IPv6:2001:16d8:ff9f::5e7:227:6b24:fed9] (unknown [IPv6:2001:16d8:ff9f:0:5e7:227:6b24:fed9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id 2E71818E19F; Thu, 10 Oct 2013 20:38:08 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. From: =?iso-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: Date: Thu, 10 Oct 2013 20:38:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <193DD662-CB03-412F-A170-AD28BA67C612@pean.org> References: <201310091810.r99IA3mS098467@freefall.freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1508) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 18:38:19 -0000 Sorry, had to rebuild kernel with debug symbols.=20 Heres the output: (kgdb) list *0xc0800110 0xc0800110 is in jenkins_hash32 = (/usr/src/sys/libkern/jenkins_hash.c:177). 172 switch(length) /* all the case statements = fall through */ 173 {=20 174 case 3 : c+=3Dk[2]; 175 case 2 : b+=3Dk[1]; 176 case 1 : a+=3Dk[0]; 177 final(a,b,c); 178 case 0: /* case 0: nothing left to add */ 179 break; 180 } 181 /*------------------------------------------------------ = report the result */ On Oct 9, 2013, at 11:18 PM, Adrian Chadd wrote: > Hi, >=20 > Is there a backtrace for this? Iv'e not seen this before. >=20 >=20 > -adrian From owner-freebsd-net@FreeBSD.ORG Thu Oct 10 22:31:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BFBDF4F6 for ; Thu, 10 Oct 2013 22:31:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8045B23E2 for ; Thu, 10 Oct 2013 22:31:28 +0000 (UTC) Received: by mail-qe0-f52.google.com with SMTP id w7so2567155qeb.25 for ; Thu, 10 Oct 2013 15:31:27 -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=B84xYMAXvzyv4pR2tQXp/yA+eJK0GtpZga9Oaq3NstQ=; b=Tg0m6DdFNxCA6gxOh82Oi8QSgLiosnCVRgBeKA7xvE1jBJTHaGEaqHZgxIsCRKSu39 lUuD3Vmfote1e3eC8dVcvOSLkfOGU77Yp7fNU35GKILShzxqZNDjC9o4bkc0jG7aiWUQ VMDB859Axm7IYdCSdaWo3Bj7X05ilvw7mOYTMwEqakCdanP1W4Aka1wCh8/gzQkfjkqJ FM19sUVM5FzV5HEXkEIFFCYM7Lkb/eYave09EUGmGhc+X63XrwUMuiGivm4KlwxIheKU /4INA39w+/R+hBF9isxPccVq8T20Y9KajbkfUKeVIY8UsHlZvWJlx34J22L0ioZwRqrb KzkA== MIME-Version: 1.0 X-Received: by 10.49.59.115 with SMTP id y19mr15454373qeq.8.1381444287736; Thu, 10 Oct 2013 15:31:27 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 10 Oct 2013 15:31:27 -0700 (PDT) In-Reply-To: <193DD662-CB03-412F-A170-AD28BA67C612@pean.org> References: <201310091810.r99IA3mS098467@freefall.freebsd.org> <193DD662-CB03-412F-A170-AD28BA67C612@pean.org> Date: Thu, 10 Oct 2013 15:31:27 -0700 X-Google-Sender-Auth: F8cI_0E9uXxoBAFE-50pM8CdvhY Message-ID: Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. From: Adrian Chadd To: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 22:31:28 -0000 what's the backtrace from the kernel crash? That's a bit odd.. :-) -adiran On 10 October 2013 11:38, Peter Ankerst=E5l wrote: > Sorry, had to rebuild kernel with debug symbols. > > Heres the output: > > (kgdb) list *0xc0800110 > 0xc0800110 is in jenkins_hash32 (/usr/src/sys/libkern/jenkins_hash.c:177)= . > 172 switch(length) /* all the case statements > fall through */ > 173 { > 174 case 3 : c+=3Dk[2]; > 175 case 2 : b+=3Dk[1]; > 176 case 1 : a+=3Dk[0]; > 177 final(a,b,c); > 178 case 0: /* case 0: nothing left to add */ > 179 break; > 180 } > 181 /*------------------------------------------------------ report > the result */ > > > On Oct 9, 2013, at 11:18 PM, Adrian Chadd wrote: > > > Hi, > > > > Is there a backtrace for this? Iv'e not seen this before. > > > > > > -adrian > > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 11 07:36:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0264774C; Fri, 11 Oct 2013 07:36:32 +0000 (UTC) (envelope-from peter@pean.org) Received: from velox.its.uu.se (velox.its.uu.se [130.238.7.74]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C0602DEE; Fri, 11 Oct 2013 07:36:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at uu.se Received: from nyx.uppmax.uu.se (nyx.uppmax.uu.se [130.238.137.40]) by velox.its.uu.se (Postfix) with ESMTP id D0AEC164016; Fri, 11 Oct 2013 09:28:42 +0200 (CEST) Message-ID: <5257A8AC.40703@pean.org> Date: Fri, 11 Oct 2013 09:28:44 +0200 From: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130807 Thunderbird/17.0.8 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. References: <201310091810.r99IA3mS098467@freefall.freebsd.org> <193DD662-CB03-412F-A170-AD28BA67C612@pean.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 07:36:32 -0000 Hi! Here is a new crash. I have wlan0 set up with ath0 as wlandev and then when I run: # ifconfig wlan1 create wlanmode hostap wlandev ath1 the machine crashes with this message: Oct 11 09:25:00 gw syslogd: kernel boot file is /boot/kernel/kernel Oct 11 09:25:00 gw kernel: Oct 11 09:25:00 gw kernel: Oct 11 09:25:00 gw kernel: Fatal trap 12: page fault while in kernel mode Oct 11 09:25:00 gw kernel: cpuid = 1; apic id = 01 Oct 11 09:25:00 gw kernel: fault virtual address = 0x0 Oct 11 09:25:00 gw kernel: fault code = supervisor read, page not present Oct 11 09:25:00 gw kernel: instruction pointer = 0x20:0xc0800600 Oct 11 09:25:00 gw kernel: stack pointer = 0x28:0xe8d879e0 Oct 11 09:25:00 gw kernel: frame pointer = 0x28:0xe8d879e8 Oct 11 09:25:00 gw kernel: wlan1: Ethernet address: b0:48:7a:d5:fe:a2 Oct 11 09:25:00 gw kernel: code segment = base 0x0, limit 0xfffff, type 0x1b Oct 11 09:25:00 gw kernel: = DPL 0, pres 1, def32 1, gran 1 Oct 11 09:25:00 gw kernel: processor eflags = interrupt enabled, resume, IOPL = 0 Oct 11 09:25:00 gw kernel: current process = 2968 (bsnmpd) Oct 11 09:25:00 gw kernel: trap number = 12 Oct 11 09:25:00 gw kernel: panic: page fault Oct 11 09:25:00 gw kernel: cpuid = 1 Oct 11 09:25:00 gw kernel: KDB: stack backtrace: Oct 11 09:25:00 gw kernel: #0 0xc078bfc2 at kdb_backtrace+0x52 Oct 11 09:25:00 gw kernel: #1 0xc07567f1 at panic+0x121 Oct 11 09:25:00 gw kernel: #2 0xc0a4ffb9 at trap_fatal+0x339 Oct 11 09:25:00 gw kernel: #3 0xc0a5024a at trap_pfault+0x27a Oct 11 09:25:00 gw kernel: #4 0xc0a4fa46 at trap+0x5a6 Oct 11 09:25:00 gw kernel: #5 0xc0a3a20c at calltrap+0x6 Oct 11 09:25:00 gw kernel: #6 0xc083f635 at ieee80211_ioctl_getstainfo+0x55 Oct 11 09:25:00 gw kernel: #7 0xc083b244 at ieee80211_ioctl_get80211+0x434 Oct 11 09:25:00 gw kernel: #8 0xc08650b8 at in_control+0x228 Oct 11 09:25:00 gw kernel: #9 0xc080df53 at ifioctl+0x1943 Oct 11 09:25:00 gw kernel: #10 0xc07a7d5c at soo_ioctl+0x30c Oct 11 09:25:00 gw kernel: #11 0xc07a0b4b at kern_ioctl+0x19b Oct 11 09:25:00 gw kernel: #12 0xc07a0969 at sys_ioctl+0xe9 Oct 11 09:25:00 gw kernel: #13 0xc0a50823 at syscall+0x363 Oct 11 09:25:00 gw kernel: #14 0xc0a3a271 at Xint0x80_syscall+0x21 On 10/11/2013 12:31 AM, Adrian Chadd wrote: > what's the backtrace from the kernel crash? > > That's a bit odd.. :-) > > > > -adiran > > > > On 10 October 2013 11:38, Peter Ankerstål > wrote: > > Sorry, had to rebuild kernel with debug symbols. > > Heres the output: > > (kgdb) list *0xc0800110 > 0xc0800110 is in jenkins_hash32 > (/usr/src/sys/libkern/jenkins_hash.c:177). > 172 switch(length) /* all the case > statements fall through */ > 173 { > 174 case 3 : c+=k[2]; > 175 case 2 : b+=k[1]; > 176 case 1 : a+=k[0]; > 177 final(a,b,c); > 178 case 0: /* case 0: nothing left to add */ > 179 break; > 180 } > 181 /*------------------------------------------------------ > report the result */ > > > On Oct 9, 2013, at 11:18 PM, Adrian Chadd > wrote: > > > Hi, > > > > Is there a backtrace for this? Iv'e not seen this before. > > > > > > -adrian > > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 11 15:20:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 822DC7C for ; Fri, 11 Oct 2013 15:20:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 41E5D2C7A for ; Fri, 11 Oct 2013 15:20:07 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id 1so999195qee.23 for ; Fri, 11 Oct 2013 08:20:06 -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=2JnnFv/bQBygrFeCfIG9dvtwOmddna/TNXTwjbnYMWQ=; b=lAUaVbdvFAJNHetG+O5QQ/upYT8G8QH4f4+Ak89CSbzXUNIcNvNxDv3PKuQVLHynlH 6zofKZCZN0/9P0V0IwJ7ls07vfcwjMTVEP+Fkf2S0oaI73UOM3g8ZJS9SI4hSoFmsd8a HUZfZdE8klfSIGUBRd3KEh6Z2bjAGZE0t97C/3feFrMLsIfL6cvPMVvB9aeICXxHoRlZ ufWoKcvBQpmOjo2OlK+NllXMX9XJ1pHpLZzMq0QdnLwgulfmdMQ5tS9ydFTyLdrrEKRj Yj5PZFbdNSqcqqDNu0gRGR6VUg9lNleKaiX+IDbkN3XT5TlhflZorKSsTFFWc+VHBF7Z b1RQ== MIME-Version: 1.0 X-Received: by 10.229.118.10 with SMTP id t10mr31500744qcq.5.1381504806211; Fri, 11 Oct 2013 08:20:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Fri, 11 Oct 2013 08:20:06 -0700 (PDT) In-Reply-To: <5257A8AC.40703@pean.org> References: <201310091810.r99IA3mS098467@freefall.freebsd.org> <193DD662-CB03-412F-A170-AD28BA67C612@pean.org> <5257A8AC.40703@pean.org> Date: Fri, 11 Oct 2013 08:20:06 -0700 X-Google-Sender-Auth: Tir0ndvXKIbvgYznzZGy8CWbNUs Message-ID: Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. From: Adrian Chadd To: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:20:07 -0000 what's wlan0 setup as? -a On 11 October 2013 00:28, Peter Ankerst=E5l wrote: > Hi! > > Here is a new crash. > > I have wlan0 set up with ath0 as wlandev and then when I run: > > # ifconfig wlan1 create wlanmode hostap wlandev ath1 > > > the machine crashes with this message: > > Oct 11 09:25:00 gw syslogd: kernel boot file is /boot/kernel/kernel > Oct 11 09:25:00 gw kernel: > Oct 11 09:25:00 gw kernel: > Oct 11 09:25:00 gw kernel: Fatal trap 12: page fault while in kernel mode > Oct 11 09:25:00 gw kernel: cpuid =3D 1; apic id =3D 01 > Oct 11 09:25:00 gw kernel: fault virtual address =3D 0x0 > Oct 11 09:25:00 gw kernel: fault code =3D supervisor read, page > not present > Oct 11 09:25:00 gw kernel: instruction pointer =3D 0x20:0xc0800600 > Oct 11 09:25:00 gw kernel: stack pointer =3D 0x28:0xe8d879= e0 > Oct 11 09:25:00 gw kernel: frame pointer =3D 0x28:0xe8d879= e8 > Oct 11 09:25:00 gw kernel: wlan1: Ethernet address: b0:48:7a:d5:fe:a2 > Oct 11 09:25:00 gw kernel: code segment =3D base 0x0, limit 0xfff= ff, > type 0x1b > Oct 11 09:25:00 gw kernel: =3D DPL 0, pres 1, def32 1, gran 1 > Oct 11 09:25:00 gw kernel: processor eflags =3D interrupt enabled, > resume, IOPL =3D 0 > Oct 11 09:25:00 gw kernel: current process =3D 2968 (bsnmpd) > Oct 11 09:25:00 gw kernel: trap number =3D 12 > Oct 11 09:25:00 gw kernel: panic: page fault > Oct 11 09:25:00 gw kernel: cpuid =3D 1 > Oct 11 09:25:00 gw kernel: KDB: stack backtrace: > Oct 11 09:25:00 gw kernel: #0 0xc078bfc2 at kdb_backtrace+0x52 > Oct 11 09:25:00 gw kernel: #1 0xc07567f1 at panic+0x121 > Oct 11 09:25:00 gw kernel: #2 0xc0a4ffb9 at trap_fatal+0x339 > Oct 11 09:25:00 gw kernel: #3 0xc0a5024a at trap_pfault+0x27a > Oct 11 09:25:00 gw kernel: #4 0xc0a4fa46 at trap+0x5a6 > Oct 11 09:25:00 gw kernel: #5 0xc0a3a20c at calltrap+0x6 > Oct 11 09:25:00 gw kernel: #6 0xc083f635 at ieee80211_ioctl_getstainfo+** > 0x55 > Oct 11 09:25:00 gw kernel: #7 0xc083b244 at ieee80211_ioctl_get80211+0x43= 4 > Oct 11 09:25:00 gw kernel: #8 0xc08650b8 at in_control+0x228 > Oct 11 09:25:00 gw kernel: #9 0xc080df53 at ifioctl+0x1943 > Oct 11 09:25:00 gw kernel: #10 0xc07a7d5c at soo_ioctl+0x30c > Oct 11 09:25:00 gw kernel: #11 0xc07a0b4b at kern_ioctl+0x19b > Oct 11 09:25:00 gw kernel: #12 0xc07a0969 at sys_ioctl+0xe9 > Oct 11 09:25:00 gw kernel: #13 0xc0a50823 at syscall+0x363 > Oct 11 09:25:00 gw kernel: #14 0xc0a3a271 at Xint0x80_syscall+0x21 > > > > On 10/11/2013 12:31 AM, Adrian Chadd wrote: > >> what's the backtrace from the kernel crash? >> >> That's a bit odd.. :-) >> >> >> >> -adiran >> >> >> >> On 10 October 2013 11:38, Peter Ankerst=E5l > > wrote: >> >> Sorry, had to rebuild kernel with debug symbols. >> >> Heres the output: >> >> (kgdb) list *0xc0800110 >> 0xc0800110 is in jenkins_hash32 >> (/usr/src/sys/libkern/jenkins_**hash.c:177). >> 172 switch(length) /* all the case >> statements fall through */ >> 173 { >> 174 case 3 : c+=3Dk[2]; >> 175 case 2 : b+=3Dk[1]; >> 176 case 1 : a+=3Dk[0]; >> 177 final(a,b,c); >> 178 case 0: /* case 0: nothing left to add */ >> 179 break; >> 180 } >> 181 /*----------------------------**-------------------------- >> report the result */ >> >> >> On Oct 9, 2013, at 11:18 PM, Adrian Chadd > > wrote: >> >> > Hi, >> > >> > Is there a backtrace for this? Iv'e not seen this before. >> > >> > >> > -adrian >> >> >> >> > From owner-freebsd-net@FreeBSD.ORG Fri Oct 11 15:23:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C32451A7 for ; Fri, 11 Oct 2013 15:23:13 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92CEC2CD1 for ; Fri, 11 Oct 2013 15:23:13 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id as1so6574790iec.41 for ; Fri, 11 Oct 2013 08:23:13 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9b2GkzrYfM+LPVWK/zqZMKl63R0M7Q6dnhgy/91n0Jc=; b=HOOtY+Hdb7NetCtjS98I3qvV7F8hQpAkebKLT63HawBnvD77krj5u40PHv/gRAOWIc YkecmZZmhJcC2nDMDr2GcdxKzXpRiTeXgEaoF0vXK7myyLLm8lbUXg2rvLrxA4b0IB45 /Hd8dTtktMyqMUqed3KGS8/3Lr40lHbSZFxW254u4/Tv8JAoLEQaVgproN3NS7b/TEwr x6Dmz4e/cG7OD1Tw8mve0vM0Z26QVjYr3exHsL0gyUqIYpHkL57dVMjNPzdy+9kFJINg hsDm893FbAv4wbSs5BU+GBY1TKnyRikuFiW+fHYpFYOoy5q/1C1gBk7cocI2qKFJ9Lzg +5uw== X-Received: by 10.43.48.7 with SMTP id uu7mr820784icb.68.1381504992961; Fri, 11 Oct 2013 08:23:12 -0700 (PDT) Received: from [10.10.1.35] ([192.252.130.194]) by mx.google.com with ESMTPSA id hv5sm3731925igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 11 Oct 2013 08:23:12 -0700 (PDT) Message-ID: <525817DE.2040006@gmail.com> Date: Fri, 11 Oct 2013 11:23:10 -0400 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org, bagadeh@gmail.com Subject: Re: igb driver does not support altq References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:23:13 -0000 On 10/10/2013 5:56 AM, h bagade wrote: > Hi all, > > I have problem with running altq on igb cards. When trying to run altq on > these cards, it outputs an error, driver does not support altq. > > I have FreeBSD 8.3-stable and tried to fix the problem, after searching in > forums, by applying changes made to igb driver through following links: > > http://svnweb.freebsd.org/base?view=revision&revision=248906 > http://svnweb.freebsd.org/base?view=revision&revision=249339 > http://lists.freebsd.org/pipermail/svn-src-stable/2013-July/019491.html > > But it doesn't help and I still have problem with running altq on igb! > > Does anybody know from which revision the problem is solved? > Any hints would be of great help. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" Hi, Those modifications require that you define IGB_LEGACY_TX in the driver code to get ALTQ running on igb. Regards, Karim. From owner-freebsd-net@FreeBSD.ORG Fri Oct 11 17:05:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A7D70F8C for ; Fri, 11 Oct 2013 17:05:38 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (unknown [IPv6:2001:16d8:cc1e:1::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAE582433 for ; Fri, 11 Oct 2013 17:05:37 +0000 (UTC) Received: from localhost (system.jails.se [91.205.63.85]) by system.jails.se (Postfix) with SMTP id 58DE418E0FA for ; Fri, 11 Oct 2013 19:05:28 +0200 (CEST) Received: from [192.168.8.225] (unknown [193.110.198.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id 146E118E0F3; Fri, 11 Oct 2013 19:05:26 +0200 (CEST) Subject: Re: kern/182665: [wlan] Kernel panic when creating second wlandev. References: <201310091810.r99IA3mS098467@freefall.freebsd.org> <193DD662-CB03-412F-A170-AD28BA67C612@pean.org> <5257A8AC.40703@pean.org> From: =?utf-8?Q?Peter_Ankerst=C3=A5l?= Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: Date: Fri, 11 Oct 2013 18:14:16 +0200 To: Adrian Chadd X-Mailer: iPad Mail (11A501) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 17:05:38 -0000 Its a hostap. (What im trying to do is to set up a legacy 2.4GHz network on t= he other interface) > On 11 okt 2013, at 17:20, Adrian Chadd wrote: >=20 > what's wlan0 setup as? >=20 >=20 >=20 > -a >=20 >=20 >> On 11 October 2013 00:28, Peter Ankerst=C3=A5l wrote: >> Hi! >>=20 >> Here is a new crash. >>=20 >> I have wlan0 set up with ath0 as wlandev and then when I run: >>=20 >> # ifconfig wlan1 create wlanmode hostap wlandev ath1 >>=20 >>=20 >> the machine crashes with this message: >>=20 >> Oct 11 09:25:00 gw syslogd: kernel boot file is /boot/kernel/kernel >> Oct 11 09:25:00 gw kernel: >> Oct 11 09:25:00 gw kernel: >> Oct 11 09:25:00 gw kernel: Fatal trap 12: page fault while in kernel mode= >> Oct 11 09:25:00 gw kernel: cpuid =3D 1; apic id =3D 01 >> Oct 11 09:25:00 gw kernel: fault virtual address =3D 0x0 >> Oct 11 09:25:00 gw kernel: fault code =3D supervisor read, page= not present >> Oct 11 09:25:00 gw kernel: instruction pointer =3D 0x20:0xc0800600 >> Oct 11 09:25:00 gw kernel: stack pointer =3D 0x28:0xe8d879= e0 >> Oct 11 09:25:00 gw kernel: frame pointer =3D 0x28:0xe8d879= e8 >> Oct 11 09:25:00 gw kernel: wlan1: Ethernet address: b0:48:7a:d5:fe:a2 >> Oct 11 09:25:00 gw kernel: code segment =3D base 0x0, limit 0xfff= ff, type 0x1b >> Oct 11 09:25:00 gw kernel: =3D DPL 0, pres 1, def32 1, gran 1 >> Oct 11 09:25:00 gw kernel: processor eflags =3D interrupt enabled, re= sume, IOPL =3D 0 >> Oct 11 09:25:00 gw kernel: current process =3D 2968 (bsnmpd)= >> Oct 11 09:25:00 gw kernel: trap number =3D 12 >> Oct 11 09:25:00 gw kernel: panic: page fault >> Oct 11 09:25:00 gw kernel: cpuid =3D 1 >> Oct 11 09:25:00 gw kernel: KDB: stack backtrace: >> Oct 11 09:25:00 gw kernel: #0 0xc078bfc2 at kdb_backtrace+0x52 >> Oct 11 09:25:00 gw kernel: #1 0xc07567f1 at panic+0x121 >> Oct 11 09:25:00 gw kernel: #2 0xc0a4ffb9 at trap_fatal+0x339 >> Oct 11 09:25:00 gw kernel: #3 0xc0a5024a at trap_pfault+0x27a >> Oct 11 09:25:00 gw kernel: #4 0xc0a4fa46 at trap+0x5a6 >> Oct 11 09:25:00 gw kernel: #5 0xc0a3a20c at calltrap+0x6 >> Oct 11 09:25:00 gw kernel: #6 0xc083f635 at ieee80211_ioctl_getstainfo+0x= 55 >> Oct 11 09:25:00 gw kernel: #7 0xc083b244 at ieee80211_ioctl_get80211+0x43= 4 >> Oct 11 09:25:00 gw kernel: #8 0xc08650b8 at in_control+0x228 >> Oct 11 09:25:00 gw kernel: #9 0xc080df53 at ifioctl+0x1943 >> Oct 11 09:25:00 gw kernel: #10 0xc07a7d5c at soo_ioctl+0x30c >> Oct 11 09:25:00 gw kernel: #11 0xc07a0b4b at kern_ioctl+0x19b >> Oct 11 09:25:00 gw kernel: #12 0xc07a0969 at sys_ioctl+0xe9 >> Oct 11 09:25:00 gw kernel: #13 0xc0a50823 at syscall+0x363 >> Oct 11 09:25:00 gw kernel: #14 0xc0a3a271 at Xint0x80_syscall+0x21 >>=20 >>=20 >>=20 >>> On 10/11/2013 12:31 AM, Adrian Chadd wrote: >>> what's the backtrace from the kernel crash? >>>=20 >>> That's a bit odd.. :-) >>>=20 >>>=20 >>>=20 >>> -adiran >>>=20 >>>=20 >>>=20 >>> On 10 October 2013 11:38, Peter Ankerst=C3=A5l >> > wrote: >>>=20 >>> Sorry, had to rebuild kernel with debug symbols. >>>=20 >>> Heres the output: >>>=20 >>> (kgdb) list *0xc0800110 >>> 0xc0800110 is in jenkins_hash32 >>> (/usr/src/sys/libkern/jenkins_hash.c:177). >>> 172 switch(length) /* all the case >>> statements fall through */ >>> 173 { >>> 174 case 3 : c+=3Dk[2]; >>> 175 case 2 : b+=3Dk[1]; >>> 176 case 1 : a+=3Dk[0]; >>> 177 final(a,b,c); >>> 178 case 0: /* case 0: nothing left to add */ >>> 179 break; >>> 180 } >>> 181 /*------------------------------------------------------ >>> report the result */ >>>=20 >>>=20 >>> On Oct 9, 2013, at 11:18 PM, Adrian Chadd >> > wrote: >>>=20 >>> > Hi, >>> > >>> > Is there a backtrace for this? Iv'e not seen this before. >>> > >>> > >>> > -adrian >=20 From owner-freebsd-net@FreeBSD.ORG Sat Oct 12 02:35:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AEDD67A2 for ; Sat, 12 Oct 2013 02:35:09 +0000 (UTC) (envelope-from mybsd@hotmail.com) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by mx1.freebsd.org (Postfix) with ESMTP id 78CF4228B for ; Sat, 12 Oct 2013 02:35:09 +0000 (UTC) Received: from BLU0-SMTP432 ([65.55.111.71]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Oct 2013 19:34:02 -0700 X-TMN: [W46nqnnTvSoNnxxbchJBN2dvig/XAU9f] X-Originating-Email: [mybsd@hotmail.com] Message-ID: Received: from [192.168.1.101] ([14.18.248.133]) by BLU0-SMTP432.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Oct 2013 19:33:59 -0700 Date: Sat, 12 Oct 2013 10:33:54 +0800 From: mybsd To: FreeBSD Net Subject: Re: Intel 82580 lagg(4) problem In-Reply-To: References: <20130930121027.Horde.taTEbLTlKvRSSUADQ3_q1_A@webmail.polynet.lviv.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [en] X-OriginalArrivalTime: 12 Oct 2013 02:34:00.0839 (UTC) FILETIME=[82752170:01CEC6F3] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 02:35:09 -0000 Set net.link.lagg.0.use_flowid=0 not solve the problem. My system is freebsd 8.4, use the e1000 driver from freebsd 8.3 solves this problem . Should confirm that the problem is driver I have already submitted the BUG. http://www.freebsd.org/cgi/query-pr.cgi?pr=182917 From owner-freebsd-net@FreeBSD.ORG Sat Oct 12 04:58:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C40D23E5 for ; Sat, 12 Oct 2013 04:58:36 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5F8A22979 for ; Sat, 12 Oct 2013 04:58:36 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id cb5so1697266wib.1 for ; Fri, 11 Oct 2013 21:58:34 -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:cc:content-type; bh=n8nt7a5FldKuhoiCyqPqrf+hgpkLHjLuQnweYNwNuy4=; b=LSV17PlAnYCM312lPN1v9RKeoZCY4GCLgbxO7Hik+KzN5pDapTTpds21hfjg4zvZMv t5U8iS1sMCHs2YPd8B/82vEhu5X4mTJsXaSygtXMbHeHhWnhGFB2f8VWXEKU3MVyElrH 4dQLqSrYAwRbB73z907M161hXzgAlal6qGHy1NkW8RpnoR3kSAeqAUyOIvQBZad+/vqR 7y7yHqGqljSSQCX8Nwrl0A7TqQOitAgIqB7F2DfBkJxyE64vT3SiDuQf+I7yL2NWqpcA 0tcceeSmk1JXraPbPNWMELQDMo2RVFIzbgLjyNvUwJyMtpgnF8N8ge084jdtqKwINcxl cjdw== X-Received: by 10.194.120.226 with SMTP id lf2mr36114wjb.47.1381553914598; Fri, 11 Oct 2013 21:58:34 -0700 (PDT) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.119.73 with HTTP; Fri, 11 Oct 2013 21:58:14 -0700 (PDT) In-Reply-To: <525817DE.2040006@gmail.com> References: <525817DE.2040006@gmail.com> From: h bagade Date: Sat, 12 Oct 2013 08:28:14 +0330 X-Google-Sender-Auth: xVwY2hURcQzNSWC2rndUrzpNVWY Message-ID: Subject: Re: igb driver does not support altq To: Karim Fodil-Lemelin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 04:58:36 -0000 On Fri, Oct 11, 2013 at 6:53 PM, Karim Fodil-Lemelin < fodillemlinkarim@gmail.com> wrote: > On 10/10/2013 5:56 AM, h bagade wrote: > >> Hi all, >> >> I have problem with running altq on igb cards. When trying to run altq on >> these cards, it outputs an error, driver does not support altq. >> >> I have FreeBSD 8.3-stable and tried to fix the problem, after searching in >> forums, by applying changes made to igb driver through following links: >> >> http://svnweb.freebsd.org/**base?view=revision&revision=**248906 >> http://svnweb.freebsd.org/**base?view=revision&revision=**249339 >> http://lists.freebsd.org/**pipermail/svn-src-stable/2013-** >> July/019491.html >> >> But it doesn't help and I still have problem with running altq on igb! >> >> Does anybody know from which revision the problem is solved? >> Any hints would be of great help. >> ______________________________**_________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/**mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org >> " >> > Hi, > > Those modifications require that you define IGB_LEGACY_TX in the driver > code to get ALTQ running on igb. > > Regards, > > Karim. > I did so but It was not successful! I may missed something but I don't know what it may be! From owner-freebsd-net@FreeBSD.ORG Sat Oct 12 10:50:10 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 86A9F811; Sat, 12 Oct 2013 10:50:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1A68926B2; Sat, 12 Oct 2013 10:50:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r9CAo4ll052445; Sat, 12 Oct 2013 13:50:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r9CAo4ll052445 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r9CAo44i052444; Sat, 12 Oct 2013 13:50:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 12 Oct 2013 13:50:04 +0300 From: Konstantin Belousov To: Jack Vogel Subject: Re: igb(4) panic: already enqueue Message-ID: <20131012105004.GK41229@kib.kiev.ua> References: <20130928213038.GT41229@kib.kiev.ua> <20130928224501.GX41229@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j69RFMfUlOFEcxqm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Jack F Vogel , hiren panchasara , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 10:50:10 -0000 --j69RFMfUlOFEcxqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 09, 2013 at 10:56:25AM -0700, Jack Vogel wrote: > Give the new driver I just committed to HEAD a try to verify/falsify a fix > please. >=20 Updated driver seemingly fixed my issue with the drdb panic, thank you. The tx busdma map leakage is still there. > Regards, >=20 > Jack >=20 >=20 >=20 > On Wed, Oct 9, 2013 at 10:23 AM, hiren panchasara < > hiren.panchasara@gmail.com> wrote: >=20 > > Jack, > > I am also seeing similar panics at $work on a couple weeks old STABLE-9. > > > > Can you please look into this issue? > > > > cheers, > > Hiren > > > > 1) HP DL360e Gen8, 2 x Xeon E5-2430 2.20GHz > > > > panic: buf=3D0xfffffe002810d700 already enqueue at 995 prod=3D997 cons= =3D995 > > cpuid =3D 17 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > > 0xffffff868637b030 > > kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff868637b0f0 > > panic() at panic+0x1d8/frame 0xffffff868637b1f0 > > igb_mq_start() at igb_mq_start+0x1cb/frame 0xffffff868637b240 > > ether_output_frame() at ether_output_frame+0x33/frame 0xffffff868637b260 > > ether_output() at ether_output+0x52d/frame 0xffffff868637b2f0 > > ip_output() at ip_output+0xe38/frame 0xffffff868637b3e0 > > tcp_output() at tcp_output+0x122c/frame 0xffffff868637b5a0 > > tcp_do_segment() at tcp_do_segment+0x306c/frame 0xffffff868637b6c0 > > tcp_input() at tcp_input+0x909/frame 0xffffff868637b7f0 > > ip_input() at ip_input+0xbd/frame 0xffffff868637b840 > > netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xffffff868637= b8a0 > > ether_demux() at ether_demux+0x17d/frame 0xffffff868637b8d0 > > ether_nh_input() at ether_nh_input+0x208/frame 0xffffff868637b910 > > netisr_dispatch_src() at netisr_dispatch_src+0x152/frame 0xffffff868637= b970 > > igb_rxeof() at igb_rxeof+0x394/frame 0xffffff868637b9e0 > > igb_handle_que() at igb_handle_que+0x9b/frame 0xffffff868637ba20 > > taskqueue_run_locked() at taskqueue_run_locked+0x93/frame > > 0xffffff868637ba80 > > taskqueue_thread_loop() at taskqueue_thread_loop+0x3e/frame > > 0xffffff868637baa0 > > fork_exit() at fork_exit+0x135/frame 0xffffff868637baf0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff868637baf0 > > > > 2) HP DL160 G6, 2 x Xeon E5620 2.40GHz > > > > panic: buf=3D0xfffffe01b6334700 already enqueue at 42 prod=3D43 cons=3D= 42 > > cpuid =3D 0 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > > 0xffffff800037a620 > > kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff800037a6e0 > > panic() at panic+0x1d8/frame 0xffffff800037a7e0 > > igb_mq_start() at igb_mq_start+0x1cb/frame 0xffffff800037a830 > > ether_output_frame() at ether_output_frame+0x33/frame 0xffffff800037a850 > > ether_output() at ether_output+0x52d/frame 0xffffff800037a8e0 > > ip_output() at ip_output+0xe38/frame 0xffffff800037a9d0 > > syncache_respond() at syncache_respond+0x462/frame 0xffffff800037aa90 > > syncache_timer() at syncache_timer+0xdf/frame 0xffffff800037aac0 > > softclock() at softclock+0x2c6/frame 0xffffff800037ab60 > > intr_event_execute_handlers() at > > intr_event_execute_handlers+0x6a/frame 0xffffff800037ab90 > > ithread_loop() at ithread_loop+0xac/frame 0xffffff800037abe0 > > fork_exit() at fork_exit+0x135/frame 0xffffff800037ac30 > > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff800037ac30 > > --j69RFMfUlOFEcxqm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSWSlbAAoJEJDCuSvBvK1B+wQP/1+ydF2dQzICKqLUeLEaptjP xuOc0FEtbTKBoG35PKRxDGwdy0Rlf/ixVWMB2sYQGImlIx/WlidwrL06jUQ3UNlz vK57UqM+j2L3XdlHeDEg3hmmrUZTqtiXqG2Rr+WpJ9tjiCBuhHBwQ1lTtrEUG6ia iDJnX3jmC6qcd+5wIHxVp0xK/ioh48k+kt8XS7uDJVLNJ/vkcoApipg3ZRaBn75/ pfvB386LuUQtdo5L/OxTb0kuxYZx2G8xzTqUAFf5o6QNyiOUbzaZkQIaELG6mBWu xPFC7UooYpS9jAwP9XsJaNrbJK98RTv/r954wYca6GWgwi5Sr0+muLyx3qYdw4C/ n98fLkARw+19WWxxzvmKOTUMXh7+Ir7zJewCu04e33Wo52tWw8J7pAhJ7oZ5o8le Vp+SrUJXoF/M/1Nrhjnm7Y7vySSQv4VP92OUQkmLUFRo8j7+SwVdRs0AZ3m0TYsX jTv2rfxLzGLGxdTj6pXTblVXpv78r8O9rXJpE1uaXBmGWU0vZvVJd9lOAIgWBv9k 4L9JawAiGY3fOpKkN2EM7+H05z/4ltirssZH7C2vJsNpSLgA82k17f2uqDqnBBsV sOjbjBHkofQhoHgU1KDwBihG9M1X4a53H5CTaqmXnkXwU9vn99OaC5UdVYHVR7t+ +UrzfxKgBM961IDN3HIr =b3Mr -----END PGP SIGNATURE----- --j69RFMfUlOFEcxqm-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 12 19:07:03 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1EBB564F; Sat, 12 Oct 2013 19:07:03 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF6C22C4C; Sat, 12 Oct 2013 19:07:02 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id gd11so3811285vcb.33 for ; Sat, 12 Oct 2013 12:07:01 -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=4Ya/H0TOlRtTzMCHXxDEF/8tNTb359Iluk5I4gZvdYo=; b=xvCT5FcofYkyfM5nRi0yEdF0ui7ZGEJwMQb2E62mvPra8CJhQ6kwIAhFcdHBh82ba0 DLRY7MsjaFyzWeoN3WUXYzi6guUgpMW0two+CpQg+sQkAdiWTJfEdcXTL9Z0nSIEmhRa n+uamoRwK8FA2xpXid27TpdMzTkcYJXTKNeWSt+R1bl9ExhGpYVQhbMIFL8Z9tBuc/58 FmfFlDGI8n4VGtM/azv7hy8yonXD06orqZVETmWEktXs7FyTQelkbnDhlib2ryaYfywT rk9etwiR4cwACrhO5eVsi9BHSZuvAEU2Dcj/yv9zTocWEiw0jY+PiMrWNR7X8DgcNqUw WFMg== MIME-Version: 1.0 X-Received: by 10.221.64.17 with SMTP id xg17mr26710829vcb.5.1381604821359; Sat, 12 Oct 2013 12:07:01 -0700 (PDT) Received: by 10.220.159.141 with HTTP; Sat, 12 Oct 2013 12:07:01 -0700 (PDT) In-Reply-To: <20131012105004.GK41229@kib.kiev.ua> References: <20130928213038.GT41229@kib.kiev.ua> <20130928224501.GX41229@kib.kiev.ua> <20131012105004.GK41229@kib.kiev.ua> Date: Sat, 12 Oct 2013 12:07:01 -0700 Message-ID: Subject: Re: igb(4) panic: already enqueue From: Jack Vogel To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jack F Vogel , hiren panchasara , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 19:07:03 -0000 Good, and I'll get the map changes in after the weekend. Jack On Sat, Oct 12, 2013 at 3:50 AM, Konstantin Belousov wrote: > On Wed, Oct 09, 2013 at 10:56:25AM -0700, Jack Vogel wrote: > > Give the new driver I just committed to HEAD a try to verify/falsify a > fix > > please. > > > Updated driver seemingly fixed my issue with the drdb panic, thank you. > > The tx busdma map leakage is still there. > > Regards, > > > > Jack > > > > > > > > On Wed, Oct 9, 2013 at 10:23 AM, hiren panchasara < > > hiren.panchasara@gmail.com> wrote: > > > > > Jack, > > > I am also seeing similar panics at $work on a couple weeks old > STABLE-9. > > > > > > Can you please look into this issue? > > > > > > cheers, > > > Hiren > > > > > > 1) HP DL360e Gen8, 2 x Xeon E5-2430 2.20GHz > > > > > > panic: buf=0xfffffe002810d700 already enqueue at 995 prod=997 cons=995 > > > cpuid = 17 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > > > 0xffffff868637b030 > > > kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff868637b0f0 > > > panic() at panic+0x1d8/frame 0xffffff868637b1f0 > > > igb_mq_start() at igb_mq_start+0x1cb/frame 0xffffff868637b240 > > > ether_output_frame() at ether_output_frame+0x33/frame > 0xffffff868637b260 > > > ether_output() at ether_output+0x52d/frame 0xffffff868637b2f0 > > > ip_output() at ip_output+0xe38/frame 0xffffff868637b3e0 > > > tcp_output() at tcp_output+0x122c/frame 0xffffff868637b5a0 > > > tcp_do_segment() at tcp_do_segment+0x306c/frame 0xffffff868637b6c0 > > > tcp_input() at tcp_input+0x909/frame 0xffffff868637b7f0 > > > ip_input() at ip_input+0xbd/frame 0xffffff868637b840 > > > netisr_dispatch_src() at netisr_dispatch_src+0x152/frame > 0xffffff868637b8a0 > > > ether_demux() at ether_demux+0x17d/frame 0xffffff868637b8d0 > > > ether_nh_input() at ether_nh_input+0x208/frame 0xffffff868637b910 > > > netisr_dispatch_src() at netisr_dispatch_src+0x152/frame > 0xffffff868637b970 > > > igb_rxeof() at igb_rxeof+0x394/frame 0xffffff868637b9e0 > > > igb_handle_que() at igb_handle_que+0x9b/frame 0xffffff868637ba20 > > > taskqueue_run_locked() at taskqueue_run_locked+0x93/frame > > > 0xffffff868637ba80 > > > taskqueue_thread_loop() at taskqueue_thread_loop+0x3e/frame > > > 0xffffff868637baa0 > > > fork_exit() at fork_exit+0x135/frame 0xffffff868637baf0 > > > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff868637baf0 > > > > > > 2) HP DL160 G6, 2 x Xeon E5620 2.40GHz > > > > > > panic: buf=0xfffffe01b6334700 already enqueue at 42 prod=43 cons=42 > > > cpuid = 0 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > > > 0xffffff800037a620 > > > kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff800037a6e0 > > > panic() at panic+0x1d8/frame 0xffffff800037a7e0 > > > igb_mq_start() at igb_mq_start+0x1cb/frame 0xffffff800037a830 > > > ether_output_frame() at ether_output_frame+0x33/frame > 0xffffff800037a850 > > > ether_output() at ether_output+0x52d/frame 0xffffff800037a8e0 > > > ip_output() at ip_output+0xe38/frame 0xffffff800037a9d0 > > > syncache_respond() at syncache_respond+0x462/frame 0xffffff800037aa90 > > > syncache_timer() at syncache_timer+0xdf/frame 0xffffff800037aac0 > > > softclock() at softclock+0x2c6/frame 0xffffff800037ab60 > > > intr_event_execute_handlers() at > > > intr_event_execute_handlers+0x6a/frame 0xffffff800037ab90 > > > ithread_loop() at ithread_loop+0xac/frame 0xffffff800037abe0 > > > fork_exit() at fork_exit+0x135/frame 0xffffff800037ac30 > > > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff800037ac30 > > > >