From owner-freebsd-hackers@freebsd.org Mon Apr 23 05:57:10 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CADD0FBF972 for ; Mon, 23 Apr 2018 05:57:09 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6186481A46 for ; Mon, 23 Apr 2018 05:57:09 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-it0-x236.google.com with SMTP id 186-v6so9254634itu.0 for ; Sun, 22 Apr 2018 22:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DOofGcZbLqEAXybNFWDO4IqlDt2VuGdrKT3RUtM2znk=; b=bLBU74KEni/m6ThhePmcf6c/4rkhZSRj0IGaK/bH8gCTb3VL2vV7dv13xH0KI9pn+P 1x2ph7POuf/+FRkLicZeq4t/eoJf7jKuncUX2NQFrlgxk3p5GEKO5OggQqJf56u4DNWC cBH7X2ZjmfwjfxFVpAhqqhw3IvddUKN1+CExZI8La+6LsPX4sPNvTW3byF153kk9e1ot cS6Scrwfp8vmsssKT3B9Es77m0NrB21mBxKyAIlbivB3/nAcWDVnmgC6KZvrJkiiDhNM ngvIfU3vpUD3wjaP+yrmbQrrXd+GtDT3K0UXVMGHefCsBCC/s6nfVnvDrHtXrFHhuWMr QFeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DOofGcZbLqEAXybNFWDO4IqlDt2VuGdrKT3RUtM2znk=; b=IOVavG+DZdzvBpCbn7+vMthBbcl+VKMW/91zl+Z3cdAR2l+N96R50J0456iUT7GE+g 12XQWUnm7RvbHPgorrcj26lNT6Leo6atuqrCko6ia/ExzXeS9Z7HlCgVewyL0Vgi2Ohn WvATHOSeE8U5/Zam+oEo9WUpi44bfRgWDCzL+UMIUeDVJqdNY1BTeG1eExzkdaHyJKsD 6GC2OcHlj7AmHuvf5BYj7z2TaAvJpu7c/w4l2mA4Aw5pe8U5km6sfftJDNs66Kw0q1uI eO7XrO8pLIAdC9wd6R+ScGwCdZMO3cCYwU2tHWWssz0a5hvqcem2spoDL3CEYhc9tUgL cRyg== X-Gm-Message-State: ALQs6tALY9XF0j0d7st3pI0ZAfSEogGvFPvXFrsFYrzIy12XDHGBAnhL 5JH+0bUMUZowksLwybTTm5Wpu5RZWDdMeAOHnQc= X-Google-Smtp-Source: AIpwx48fuY+0xZKbn6EDnSY9xv1GzNvZ5XLpQCRf1P82m5Kq2MAos3NzFJ2fxQCm0IfzM7v6plN2l3H8a1+AL31nPsQ= X-Received: by 2002:a24:10c7:: with SMTP id 190-v6mr12488905ity.38.1524463027756; Sun, 22 Apr 2018 22:57:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.131.43 with HTTP; Sun, 22 Apr 2018 22:57:07 -0700 (PDT) From: Dieter BSD Date: Sun, 22 Apr 2018 22:57:07 -0700 Message-ID: Subject: Re: Realtek re(4) driver To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 05:57:10 -0000 With several days more data, the Realtek driver is slightly different than the stock FreeBSD 10.3 driver, but it still fails a lot, with both TCP and UDP. > Has anyone tried similar testing? > Suggestions of knobs to turn, or other things to try? > I need to receive data via UDP without dropping packets. > Closed source sucks, but I'm stuck with it, and thus with UDP. Gary typed: >> Everyone blames re, but AFAICT >> no-one switched to a non-Realtek chip to run tests and prove that, >> yes, re is really the cause of all the network problems. I have a box with nfe(4) and bge(4) (BCM5750) that can receive data with UDP or TCP without error. This has been working for several years. But a newer, faster machine with re(4) 8111E & 8111F cannot. The nfe is in the chipset, and the BCM5750 is onboard. I had google look for an expansion card with BCM5750 but found nothing. I'm looking into a Broadcom 5719 card, but there is at least one open PR against it, so... Alex typed: > surely it's not a NFS issue NFS is a bug. By design. "Not a File System" My machines are NFS-free. > The only thing that link all bug reports > (and there are tons) is the use of re card sustaining gigabit (duplex) > transfers. My re run (1000baseT ) but the pauses happen even with light traffic. You don't have to run them full blast with rcp/ftp/whatever to get failures. STefan typed: > Well, but you know that the U in UDP means unreliable? Well, :-) you didn't pay attention when I said exactly that: >>> Something like a rcp(1) with another >>> FreeBSD box merely runs slower due to the stalls, but if the other end >>> has buggy network code and/or if the transfer is forced to use UDP >>> (Unreliable Data Protocol) data is lost. :-( >> With reasonably decent network software and TCP, this is only a minor >> problem. However with buggy network software (like a "black box" >> with closed source firmware and maybe a transmit buffer that is *way* >> too small, and/or true real time requirements), and/or with a brain dead >> protocol like UDP, you can lose data. rcp(1) to 8111F using Realtek driver Both machines basically idle. mtu=9000 on both ends but appears to be using 1500 anyway? netstat -w 1 -d -I re0 input re0 output packets errs idrops bytes packets errs bytes colls drops 5 0 0 330 6 0 755 0 0 4 0 0 264 4 0 564 0 0 5 0 0 331 5 0 630 0 0 17454 0 0 26176844 17453 0 1152264 0 0 67883 0 0 101023187 67880 0 4481248 0 0 52133 0 0 77141014 52140 0 3444580 0 0 72410 0 0 107980584 72409 0 4780384 0 0 80736 0 0 120645177 80735 0 5328810 0 0 71898 0 0 107298972 71899 0 4745634 0 0 14452 0 0 21510681 14475 0 955577 0 0 5 0 0 330 6 0 755 0 0 4 0 0 264 4 0 564 0 0 5 0 0 331 5 0 630 0 0 4 0 0 264 4 0 564 0 0 65323 0 0 97533279 65321 0 4311552 0 0 28383 0 0 42398766 28385 0 1873769 0 0 80759 0 0 120315366 80756 0 5330394 0 0 80992 0 0 120693553 80995 0 5345772 0 0 80932 0 0 120692488 80930 0 5341746 0 0 78905 0 0 117912275 78922 0 5209152 0 0 80158 0 0 119592452 80159 0 5290728 0 0 input re0 output packets errs idrops bytes packets errs bytes colls drops 80851 0 0 120590446 80852 0 5336591 0 0 80849 0 0 120589243 80847 0 5336334 0 0 80858 0 0 120598524 80860 0 5336928 0 0 15085 0 0 22529747 15107 0 997296 0 0 4 0 0 264 4 0 564 0 0 4 0 0 264 4 0 564 0 0 5 0 0 331 5 0 630 0 0 4 0 0 264 4 0 564 0 0 63944 0 0 95447185 63943 0 4220604 0 0 80588 0 0 120276192 80589 0 5319233 0 0 80721 0 0 120480130 80722 0 5328011 0 0 79870 0 0 119139685 79870 0 5271720 0 0 79425 0 0 118587402 79442 0 5243472 0 0 80609 0 0 120333747 80609 0 5320494 0 0 80852 0 0 120624944 80850 0 5336532 0 0 80827 0 0 120555558 80831 0 5335073 0 0 79185 0 0 118137499 79185 0 5226510 0 0 76417 0 0 114252562 76431 0 5045010 0 0 79896 0 0 119330393 79900 0 5273436 0 0 79455 0 0 118627478 79456 0 5244330 0 0 77667 0 0 116033902 77662 0 5126256 0 0 input re0 output packets errs idrops bytes packets errs bytes colls drops 79517 0 0 118735507 79515 0 5248547 0 0 78557 0 0 117304898 78578 0 5186118 0 0 79607 0 0 118742143 79625 0 5255616 0 0 79776 0 0 119140720 79775 0 5265450 0 0 75105 0 0 112725906 75107 0 4957230 0 0 79214 0 0 118774181 79214 0 5228424 0 0 13090 0 0 19520508 13113 0 865692 0 0 Same as above except to 2nd 8111F port. input re1 output packets errs idrops bytes packets errs bytes colls drops 75170 0 0 112288950 75165 0 4960956 0 0 74149 0 0 110808698 74150 0 4893834 0 0 75088 0 0 112276960 75088 0 4955808 0 0 74567 0 0 111313160 74566 0 4921356 0 0 77064 0 0 115370280 77065 0 5086290 0 0 71606 0 0 107343414 71622 0 4727052 0 0 70831 0 0 105956278 70832 0 4674849 0 0 70727 0 0 106127094 70725 0 4667916 0 0 73427 0 0 110111478 73425 0 4846182 0 0 72519 0 0 108763678 72522 0 4786320 0 0 5661 0 0 8423884 5681 0 374880 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 196 0 0 0 0 0 1 0 0 98 0 0 0 0 0 563 0 0 838984 561 0 37026 0 0 29144 0 0 43754296 29142 0 1923438 0 0 73986 0 0 110909436 73987 0 4883142 0 0 39601 0 0 59343834 39621 0 2614920 0 0 0 0 0 0 0 0 0 0 0 3 0 0 201 0 0 0 0 0 input re1 output packets errs idrops bytes packets errs bytes colls drops 0 0 0 0 0 0 0 0 0 1 0 0 98 0 0 0 0 0 567 0 0 839958 567 0 37422 0 0 1 0 0 98 0 0 0 0 0 38003 0 0 56780696 38000 0 2508066 0 0 75439 0 0 112523550 75438 0 4978908 0 0 77058 0 0 114890108 77059 0 5085894 0 0 77471 0 0 115473190 77470 0 5113020 0 0 76814 0 0 114644092 76815 0 5069790 0 0 78120 0 0 116633730 78118 0 5155788 0 0 74853 0 0 111727082 74854 0 4940298 0 0 77626 0 0 115697756 77623 0 5123250 0 0 70804 0 0 105582200 70804 0 4672998 0 0 76722 0 0 114492148 76722 0 5063652 0 0 29562 0 0 44157654 29582 0 1952346 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 568 0 0 840298 566 0 37356 0 0 0 0 0 0 0 0 0 0 0 input re1 output packets errs idrops bytes packets errs bytes colls drops 43130 0 0 64590180 43128 0 2846514 0 0 29010 0 0 43374204 29032 0 1916046 0 0 0 0 0 0 0 0 0 0 0 2 0 0 134 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 515 0 0 770942 515 0 33990 0 0 17903 0 0 26853958 17902 0 1181598 0 0 74854 0 0 111699988 74851 0 4940166 0 0 77120 0 0 115061536 77117 0 5089722 0 0 76857 0 0 114664362 76855 0 5072562 0 0 75817 0 0 113174146 75820 0 5003988 0 0 76737 0 0 114435914 76737 0 5064642 0 0 78495 0 0 117128814 78493 0 5180604 0 0 75723 0 0 112970948 75724 0 4997718 0 0 76501 0 0 114196604 76500 0 5049066 0 0 76187 0 0 113779382 76189 0 5028408 0 0 77236 0 0 115269384 77235 0 5097510 0 0 75300 0 0 112389128 75300 0 4969800 0 0 76492 0 0 114455568 76492 0 5048472 0 0 75573 0 0 113011418 75572 0 4987752 0 0 input re1 output packets errs idrops bytes packets errs bytes colls drops 73331 0 0 109541752 73330 0 4839780 0 0 76732 0 0 114631816 76733 0 5064378 0 0 74400 0 0 111067456 74399 0 4910334 0 0 75974 0 0 113463012 75975 0 5014350 0 0 76312 0 0 113999448 76311 0 5036526 0 0 43806 0 0 65415884 43844 0 2893638 0 0 1 0 0 66 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Same as above except to onboard 8111E. input re2 output packets errs idrops bytes packets errs bytes colls drops 53122 0 0 80345556 0 0 0 0 0 53984 0 0 81332624 0 0 0 0 0 61394 0 0 92785548 0 0 0 0 0 53421 0 0 80696090 0 0 0 0 0 30857 0 0 46597698 0 0 0 0 0 76124 0 0 115239504 0 0 0 0 0 69172 0 0 104706904 0 0 0 0 0 76094 0 0 115191956 0 0 0 0 0 76849 0 0 116329874 0 0 0 0 0 68788 0 0 104120096 0 0 0 0 0 69233 0 0 104802146 0 0 0 0 0 50527 0 0 76465702 0 0 0 0 0 75916 0 0 114920192 0 0 0 0 0 66062 0 0 99990092 0 0 0 0 0 76257 0 0 115436194 0 0 0 0 0 47074 0 0 71233028 0 0 0 0 0 51788 0 0 78359104 0 0 0 0 0 44486 0 0 67316276 0 0 0 0 0 76159 0 0 115288566 0 0 0 0 0 64766 0 0 98037852 0 0 0 0 0 76786 0 0 116237604 0 0 0 0 0 input re2 output packets errs idrops bytes packets errs bytes colls drops 50676 0 0 76688424 0 0 0 0 0 76918 0 0 116440932 0 0 0 0 0 65723 0 0 99488694 0 0 0 0 0 73756 0 0 111653288 0 0 0 0 0 71393 0 0 108070674 0 0 0 0 0 63089 0 0 95485346 0 0 0 0 0 69588 0 0 105333248 0 0 0 0 0 59215 0 0 89617670 0 0 0 0 0 57339 0 0 86752950 0 0 0 0 0 75739 0 0 114651942 0 0 0 0 0 68442 0 0 103594692 0 0 0 0 0 49990 0 0 75649100 0 0 0 0 0 27710 0 0 41940348 0 0 0 0 0 50005 0 0 75694058 0 0 0 0 0 76748 0 0 116183384 0 0 0 0 0 52088 0 0 78847168 0 0 0 0 0 76816 0 0 116287048 0 0 0 0 0 70232 0 0 106301624 0 0 0 0 0 76467 0 0 115754502 0 0 0 0 0 68979 0 0 104412918 0 0 0 0 0 76694 0 0 116101068 0 0 0 0 0 input re2 output packets errs idrops bytes packets errs bytes colls drops 68857 0 0 104224114 0 0 0 0 0 76545 0 0 115871154 0 0 0 0 0 65996 0 0 99843912 0 0 0 0 0 76674 0 0 116070772 0 0 0 0 0 68095 0 0 103070230 0 0 0 0 0 74877 0 0 113319642 0 0 0 0 0 39228 0 0 59366824 0 0 0 0 0 53026 0 0 80203068 0 0 0 0 0 ... 77799 0 0 117779926 0 0 0 0 0 72666 0 0 110007220 0 0 0 0 0 69173 0 0 104681578 0 0 0 0 0 55918 0 0 84169172 0 0 0 0 0 24127 0 0 36195390 0 0 0 0 0 input re2 output packets errs idrops bytes packets errs bytes colls drops 0 0 0 0 0 0 0 0 0 19706 0 0 29578468 0 0 0 0 0 53262 0 0 79974084 0 0 0 0 0 59033 0 0 88835122 0 0 0 0 0 54469 0 0 81830514 0 0 0 0 0 55005 0 0 82842706 0 0 0 0 0 47867 0 0 72331934 0 0 0 0 0 65468 0 0 99099624 0 0 0 0 0 80572 0 0 121980632 0 0 0 0 0 58201 0 0 88091802 0 0 0 0 0 51948 0 0 78614144 0 0 0 0 0 80053 0 0 121196242 0 0 0 0 0 52331 0 0 79200470 0 0 0 0 0 80123 0 0 121302582 0 0 0 0 0 43414 0 0 65698001 0 0 0 0 0 77961 0 0 117995130 0 0 0 0 0 62287 0 0 94226926 0 0 0 0 0 75558 0 0 114290892 0 0 0 0 0 64228 0 0 97158320 0 0 0 0 0 59981 0 0 90654186 0 0 0 0 0 43520 0 0 65739096 0 0 0 0 0 input re2 output packets errs idrops bytes packets errs bytes colls drops 56570 0 0 85335700 0 0 0 0 0 50066 0 0 75384196 0 0 0 0 0 55959 0 0 84239934 0 0 0 0 0 53192 0 0 80101232 0 0 0 0 0 49002 0 0 73982980 0 0 0 0 0 49713 0 0 74993370 0 0 0 0 0 43984 0 0 66011800 0 0 0 0 0 54324 0 0 81935448 0 0 0 0 0 48502 0 0 72734828 0 0 0 0 0 26191 0 0 39411806 0 0 0 0 0 0 0 0 0 0 0 0 0 0 42582 0 0 64021036 0 0 0 0 0 47216 0 0 70880104 0 0 0 0 0 52239 0 0 78498398 0 0 0 0 0 52517 0 0 79279690 0 0 0 0 0 44212 0 0 66384032 0 0 0 0 0 57225 0 0 86126642 0 0 0 0 0 47902 0 0 72238300 0 0 0 0 0 44933 0 0 67508656 0 0 0 0 0 54967 0 0 82411976 0 0 0 0 0 50724 0 0 76288600 0 0 0 0 0 ... input re2 output packets errs idrops bytes packets errs bytes colls drops 56426 0 0 84726988 0 0 0 0 0 53332 0 0 79840392 0 0 0 0 0 52763 0 0 78943630 0 0 0 0 0 52190 0 0 78016892 0 0 0 0 0 56889 0 0 85597554 0 0 0 0 0 55265 0 0 82915642 0 0 0 0 0 52162 0 0 78061690 0 0 0 0 0 58041 0 0 87326532 0 0 0 0 0 53244 0 0 79740088 0 0 0 0 0 51387 0 0 76791862 0 0 0 0 0 54187 0 0 81106878 0 0 0 0 0 51846 0 0 77541604 0 0 0 0 0 42316 0 0 63282584 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 590 0 0 890908 0 0 0 0 0 40253 0 0 60411290 0 0 0 0 0 56653 0 0 85264434 0 0 0 0 0 53499 0 0 80125838 0 0 0 0 0 [ ... ] input re2 output packets errs idrops bytes packets errs bytes colls drops 52839 0 0 78935238 0 0 0 0 0 53098 0 0 79307900 0 0 0 0 0 49559 0 0 74231830 0 0 0 0 0 79905 0 0 120972890 0 0 0 0 0 66836 0 0 101174008 0 0 0 0 0 75308 0 0 113998016 0 0 0 0 0 47258 0 0 71543932 0 0 0 0 0 32 0 0 48448 0 0 0 0 0 70026 0 0 106002764 0 0 0 0 0 63937 0 0 96604786 0 0 0 0 0 60947 0 0 92062662 0 0 0 0 0 63772 0 0 96410208 0 0 0 0 0 58129 0 0 87582154 0 0 0 0 0 59204 0 0 89190072 0 0 0 0 0 61375 0 0 92741230 0 0 0 0 0 69159 0 0 104622734 0 0 0 0 0 75748 0 0 114661800 0 0 0 0 0 75478 0 0 114253980 0 0 0 0 0 76814 0 0 116282228 0 0 0 0 0 76931 0 0 116458670 0 0 0 0 0 75299 0 0 113979718 0 0 0 0 0 From owner-freebsd-hackers@freebsd.org Mon Apr 23 06:01:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 62110FBFF18; Mon, 23 Apr 2018 06:01:46 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04B4981E94; Mon, 23 Apr 2018 06:01:45 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-it0-x242.google.com with SMTP id p3-v6so8957859itc.0; Sun, 22 Apr 2018 23:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=sr7IK+yULWysuf74hcf2lz0SgnxGcQZXtz8FoqAmtWY=; b=gwPMtR+EYFVn9/uxl+AwsySCaM63sL54ONKRrcVbi0TwEzG3hRK/3u/zBwFcLf5DPA 6isnPTCTnQbjx5/y5wQBPG/9JIHZX0w+C9uQD1a5M7StzzzvL4i12AhY5reyaNX0IEWZ Ryg89fUJA0+vsCQSRwkfJ6I7Nk7mVWaGxJNxDt1GF8+74tfegwW+Tj2TzRS+gG1vmwTC pXicDLc47De9vc7aeU2v9Ex9VjG4Ss1kLiUIjh2VAqWpg21opr5QUZbKPFrdfFngH22k 0A+uximrCOGLRqkksfSc/jweSPNvl/Ny3nQZf78VsE1qSQERVt/U033n8edgcIYFg0yo GKWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=sr7IK+yULWysuf74hcf2lz0SgnxGcQZXtz8FoqAmtWY=; b=SPMviKWeIuHflAiehh6cR/rce3CbAvvuhsuvZRFnLlxDKCsGBtRG+aj7gcPXLYOvKe 27SrJ8KFyhBJ5AuN3UxdCAMQVTlLzkTVLv8XTVLCqcg1c0FxMmETnkCHg/6YcjJi2LNp PFLk+oUQ5nxRoR4z0OuQxvxGumQTz2/6mvnFBDTBgIg0jY4M7IpREjzaCgpxsBT0J920 ZE2ylP7tLpsZiOF5a69OqTe8kH4jGAkVRtFLqr+JS521Dl2PrQs5S5CzvCiSHa3cr0qY HxumNFC6ydKuil4rcX+0bJU55lQZcl07EDinNIOqLEeU39rkNBds6ES1Cui0rwabkxb1 EfMQ== X-Gm-Message-State: ALQs6tB2TczvGRZFMKk35EjLbzf8jJhfXt/YqebgffZJ52S03nsZX6Xc Ykuv60hwhL1xjk1CeICB+QVljW1BwuVtcjtyzaA= X-Google-Smtp-Source: AB8JxZq/j2OuCVDsGcDBdUn8D1cIbCWgEsRoQ2Oy1kU/nhTcwHvNGC9lLNupKWYfzDXuduA8RJsiukMbBsdJotwNyUU= X-Received: by 2002:a24:a14a:: with SMTP id n10-v6mr13581777iti.66.1524463305347; Sun, 22 Apr 2018 23:01:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.131.43 with HTTP; Sun, 22 Apr 2018 23:01:45 -0700 (PDT) From: Dieter BSD Date: Sun, 22 Apr 2018 23:01:45 -0700 Message-ID: Subject: Broadcom 5719 Ethernet - Does it work yet? To: yongari@freebsd.org, freebsd-drivers@freebsd.org Cc: anders@freebsd.org, jpmg@eng.cam.ac.uk, danmason@danmason.net, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 06:01:46 -0000 www.broadcom.com/products/ethernet-connectivity/network-adapters/bcm5719-4p/ claims that FreeBSD works with the 5719, but bugs.freebsd.org/bugzilla/show_bug.cgi?id=171121 is still open, so the question of whether the 5719 works properly (or at all?) with FreeBSD is clear as mud. :-( Question 1: It appears that there were/are problems with both Dell cards and HP cards. Is there something special about these cards that could keep FreeBSD from working with them? Do they need to be in Dell/HP systems or would they work in a vanilla machine? (I'm thinking of getting one for a vanilla machine but only if it works.) The 5719 and 5720 are the same except for 4 ports vs 2 ports, right? Question 2: The PR was opened in 2012, and is still open. Do FreeBSD and the 5719 play together yet? Is anyone working on it? Question 3: For those who do have it working, are there any problems? For example, the Realtek 8111 has pauses, which can cause lost data, even with TCP. See [1] And the AX88179 silently corrupts data, even with TCP. See [2] Question 4: > I thought you don't have any working network devices on your box so > I recommended to use USB based ethernet controller(i.e. axe(4)) to > get working network on the box. The axe(4) man page lists several chips. Do any of these actually work correctly with FreeBSD? I found that the AX88179 silently corrupts data unless the data rate is very slow. For details, see [2] Question 5: > Unfortunately I didn't get any answers/hints from Broadcom. Still nothing from Broadcom? They claim it works with FreeBSD, but they will not assist? Does FreeBSD have anyone who is good at diplomaticly rattling cages? [1] See the "Realtek re(4) driver" thread on hackers@ [2] See "AX88179 USB-to-Ethernet is slow and silently corrupts data" on hackers@, drivers@, usb@, net@ From owner-freebsd-hackers@freebsd.org Mon Apr 23 07:39:53 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22684FA29DC for ; Mon, 23 Apr 2018 07:39:53 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0A37767BD for ; Mon, 23 Apr 2018 07:39:52 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x232.google.com with SMTP id y123-v6so2212332ywa.5 for ; Mon, 23 Apr 2018 00:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=e5yXMgNqv4RWcdMc/gBV5mo3/Y1Yzx63ycJTQnFH7DY=; b=dxD9nvDccndrfOLpn9jBe7AMhsr0pqRTMmMpLCQLcfgFV3GXUku59SVnHpUzcpWZdm vC2dFawWDI/VZl99mwZG9eicq55jnRikx/4VH6USd4hFMnpDyde3vy0o36qrzPnV1HWn HRkT6eWgvRuyxsmdI6QI6D93IjetNLTb1Znk4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=e5yXMgNqv4RWcdMc/gBV5mo3/Y1Yzx63ycJTQnFH7DY=; b=ZdXCuAmbKW1kDFl94KENfuwxRbq3AWujDK19LRWoiIS5T75Iw08OcUqToCNSEwR/0I o4W9V4d9vm4llS+3aLpyEY4z0xQiHGzhGmSMn2fzamqHL/rFh/YzaGa7tcfITi1luRu1 fVIwbgpZtkGZgyCT5BEPbUfdg6sB8UVFcK6St1z3gKmrVI6By06rLZYcvo0H4I05d1RI hpi6h6SfK7PxEsthZZKeucp2WFwazfvaWFDRTrEqTPYItYr6a1Espdcjhi9sAxqF4tYy mancUHwNe6tO52/OAPrrJ7Avavw4fdv2wNcbawrGf27I5ukX/dEN/i92BWvjHzY+JW0W lFUw== X-Gm-Message-State: ALQs6tBVV1RfQxibJyqOk1sWsZt6CewSnx9mEr7Nby4lyLOfnuUe6yV2 JKfFzXxVcjdRryLtSEFAOiQkPfv//z0fb9rTbpYFS6Z6 X-Google-Smtp-Source: AIpwx48Mv8YPlKY69VcUv6udX1UeNVfcM60o0lElVHhaAo+lpexobU5qQSPqnceL6uf4SYywNxfFUec/KhuahuLyu9U= X-Received: by 2002:a81:af26:: with SMTP id n38-v6mr10268751ywh.113.1524469191939; Mon, 23 Apr 2018 00:39:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:c709:0:0:0:0:0 with HTTP; Mon, 23 Apr 2018 00:39:21 -0700 (PDT) From: Eitan Adler Date: Mon, 23 Apr 2018 00:39:21 -0700 Message-ID: Subject: on shutdown: Fatal trap 9: general protection fault while in kernel mode To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 07:39:53 -0000 https://reviews.freebsd.org/P175 Kernel is trying to deref this pointer: (kgdb) p sx $1 = (struct sx *) 0xdeadc0dedeadd47e no time to debug right now, but complete kernel + dump + symbols available. -- Eitan Adler From owner-freebsd-hackers@freebsd.org Mon Apr 23 08:00:27 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE68DFA4F1F for ; Mon, 23 Apr 2018 08:00:27 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 17DFC7A9D1 for ; Mon, 23 Apr 2018 08:00:27 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: by mailman.ysv.freebsd.org (Postfix) id BD682FA4F0F; Mon, 23 Apr 2018 08:00:26 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 990ADFA4F0D for ; Mon, 23 Apr 2018 08:00:26 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu1176c.smtpx.saremail.com (cu1176c.smtpx.saremail.com [195.16.148.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B273A7A9C0; Mon, 23 Apr 2018 08:00:25 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.141] (unknown [192.148.167.11]) by proxypop02.sare.net (Postfix) with ESMTPA id 82AD59DC528; Mon, 23 Apr 2018 09:52:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Realtek re(4) driver From: Borja Marcos In-Reply-To: Date: Mon, 23 Apr 2018 09:52:49 +0200 Cc: gljennjohn@gmail.com, hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3043ED20-AAD6-46AA-8A41-11705B600A35@sarenet.es> References: <20180411121404.71a07fef@ernst.home> <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> <20180411104533.GC1134@albert.catwhisker.org> <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> <20180411155432.78b23bbe@ernst.home> To: Alex Dupre X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 08:00:28 -0000 > On 11 Apr 2018, at 17:19, Alex Dupre wrote: > I agree that is a complex problem with a non obvious solution, I have > also used many re cards successfully and others not, but surely it's = not > a NFS issue. I have this interface in an Intel NUC, re0@pci0:3:0:0: class=3D0x020000 card=3D0x20678086 chip=3D0x816810ec = rev=3D0x15 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet = Controller' class =3D network subclass =3D ethernet and I have had serious problems running an iSCSI initiator with some = work load. I tried both the builtin =E2=80=9Cre=E2=80=9D driver in FreeBSD and the 1.94.01 version = driver available from the Realtek website with similar results. More or less the same workload on a different machine with Intel = =E2=80=9Cem=E2=80=9D cards and=20 the same FreeBSD version works. Borja. From owner-freebsd-hackers@freebsd.org Mon Apr 23 08:08:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70C5EFA5C15 for ; Mon, 23 Apr 2018 08:08:28 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B88F7D78F; Mon, 23 Apr 2018 08:08:27 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.141] (unknown [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPA id 2C10F9DD824; Mon, 23 Apr 2018 09:59:50 +0200 (CEST) From: Borja Marcos Message-Id: <214C069B-940F-41B4-A417-5AF5CC3F7E09@sarenet.es> Content-Type: multipart/signed; boundary="Apple-Mail=_6003881C-7EC7-45DE-A6CE-D16A1D2BE682"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Realtek re(4) driver Date: Mon, 23 Apr 2018 09:59:48 +0200 In-Reply-To: <054b8c2c-7cd4-fdc2-d02c-d9d8e0ca3c20@freebsd.org> Cc: freebsd-hackers@freebsd.org To: Allan Jude References: <054b8c2c-7cd4-fdc2-d02c-d9d8e0ca3c20@freebsd.org> X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 08:08:28 -0000 --Apple-Mail=_6003881C-7EC7-45DE-A6CE-D16A1D2BE682 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Apr 2018, at 19:34, Allan Jude wrote: >=20 > I think it would be useful to collect the 'pciconf -lv' output of the > re(4) devices that have issues, so they can be differentiated from the > ones that work fine. There we go. The machine is an Intel NUC6CAYB. Yep, sounds stupid. Intel = using Realtek Ethernet chips. Sigh. re0: port = 0xe000-0xe 0ff mem 0x91104000-0x91104fff,0x91100000-0x91103fff at device 0.0 on = pci3 re0: Using 1 MSI-X message re0: turning off MSI enable bit. re0: Chip rev. 0x54000000 re0: MAC rev. 0x00100000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, = 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, = 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 94:c6:91:: re0@pci0:3:0:0: class=3D0x020000 card=3D0x20678086 chip=3D0x816810ec = rev=3D0x15 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL8111/8168/8411 PCI Express Gigabit Ethernet = Controller' class =3D network subclass =3D ethernet What I=E2=80=99ve observed is crazy packet loss and round trip times = especially when running an iSCSI initiator with a lot of filesystem activity. Borja. --Apple-Mail=_6003881C-7EC7-45DE-A6CE-D16A1D2BE682 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRdSxpX7rVbKGmYLxtQulWjhdaAnwUCWt2SdAAKCRBQulWjhdaA n8yoAJwMHi3vMLMcCh6xubVbivY++nXR1ACgs4Uory0JXZYYKzMqUqH2GLa8QTg= =FRAV -----END PGP SIGNATURE----- --Apple-Mail=_6003881C-7EC7-45DE-A6CE-D16A1D2BE682-- From owner-freebsd-hackers@freebsd.org Tue Apr 24 04:24:41 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06549FB9230; Tue, 24 Apr 2018 04:24:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C73487638; Tue, 24 Apr 2018 04:24:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pg0-x242.google.com with SMTP id 82so47218pge.11; Mon, 23 Apr 2018 21:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=NkOCBYEh4HvyhXn8z2lm6NInAKrdNxClPlRophR/6bY=; b=FtzkOwJHhrqAhiaO5+j5K4MFMnjMeCu0aDTDGFZBH/4wS2lyC2vluzGgs3MqCyLzBX l6NWLFXaj33MgFxWmoAi+TQtjgx2qW68gNIyquOx/ZtJIluYyxLh3f5KYpeeUzbUu0OH FfvtXOSYxfZUX7NFyonUNzyI/zcjSv8ozaJsEd+Ad1E98Ky3mcm27+Zr1EP+dJYOH57t fy7FLAVE00w8DLzjgJyekEI6PeEmYJ5dKiL+orF5wwqdzP+nPQkau4X3b8bRf45xoe4p JtLlo2/YMZKWxpnFdzrAfcvYQrkDHc9n3QBZgOpd2acsKVVIMChdZHuQa4BmGsC8H5wO fh8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=NkOCBYEh4HvyhXn8z2lm6NInAKrdNxClPlRophR/6bY=; b=HXcTodohSsExPghdfWDkh68pz6+jBOoj9Idy4sjlR/uhEWJK+YU5gfhV42Rz6a2dky 9Ud38h0TaTqunqsZSIBV/W1Uzwzhis8BshAQSvenCxD1pLkJM3k+Tabz00wvM0gdVLrU aACdcnHeQx4LNl8LaLDT6euSn4iCaHtYaX1VibwWR+tpr6tqAp8FQldzpBpcQUBT/xiP 2/xhwZR68CxIUjI46YcFYMV/u3J41idKparQNZiwIPtmKGoq037kv33cmltJE2nB1CRF /+l4VhZPNDX+rmvn7btx/oQ5R0BbseMQgAnkxVNE8VYrzXqw88d6YMd4IuDCG4BsEVkE FwwQ== X-Gm-Message-State: ALQs6tBZPbHyIHNGZFtvrFGM0lUEWto9w4TZBkEuFe40Tmt4kz3Dxb2D Zssf5jFLn/j9kBAmY9kU773rMw== X-Google-Smtp-Source: AIpwx4+H6aqyfkFmQX0bTLWzzU148XHj4J+CxSiaCXBiEArlb8ysM9KunWzimfZkw+1GPk1mDLmOrg== X-Received: by 2002:a17:902:1e3:: with SMTP id b90-v6mr20400466plb.273.1524543879611; Mon, 23 Apr 2018 21:24:39 -0700 (PDT) Received: from localhost ([58.237.141.52]) by smtp.gmail.com with ESMTPSA id l80sm29852053pfk.73.2018.04.23.21.24.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 21:24:38 -0700 (PDT) From: YongHyeon PYUN X-Google-Original-From: "YongHyeon PYUN" Received: by localhost (sSMTP sendmail emulation); Tue, 24 Apr 2018 13:24:34 +0900 Date: Tue, 24 Apr 2018 13:24:34 +0900 To: Dieter BSD Cc: yongari@freebsd.org, freebsd-drivers@freebsd.org, anders@freebsd.org, jpmg@eng.cam.ac.uk, danmason@danmason.net, freebsd-hackers@freebsd.org Subject: Re: Broadcom 5719 Ethernet - Does it work yet? Message-ID: <20180424042434.GA3123@michelle.fasterthan.co.kr> Reply-To: pyunyh@gmail.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 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 04:24:41 -0000 On Sun, Apr 22, 2018 at 11:01:45PM -0700, Dieter BSD wrote: > www.broadcom.com/products/ethernet-connectivity/network-adapters/bcm5719-4p/ > claims that FreeBSD works with the 5719, but > bugs.freebsd.org/bugzilla/show_bug.cgi?id=171121 > is still open, so the question of whether the 5719 works properly > (or at all?) with FreeBSD is clear as mud. :-( > I'm not sure but it shall work. On some HP or Dell systems with ASF/IPMI stuff, it may have some issues as the PR indicated. But I was not able to narrow down the issue at that time. > Question 1: It appears that there were/are problems with both Dell > cards and HP cards. Is there something special about these cards > that could keep FreeBSD from working with them? Do they need to be > in Dell/HP systems or would they work in a vanilla machine? > (I'm thinking of getting one for a vanilla machine but only if it works.) > The 5719 and 5720 are the same except for 4 ports vs 2 ports, right? > Preliminary ASF/IPMI support in bge(4) is included but it may not be enough to fully support customized firmware shipped on HP or Dell systems. This is one of reason why bge(4) suspend/resumes are not reliable on some server class systems. WOL support also requires complicated ASF/IPMI handshake so WOL support was not implemented at all. Blindly activating WOL on bge(4) controllers with ASF/IPMI systems may trigger more issues. > Question 2: > The PR was opened in 2012, and is still open. Do FreeBSD and the > 5719 play together yet? Is anyone working on it? Most 5719/5720 shall work. > Is anyone working on it? I'm not aware of it. > Question 3: > For those who do have it working, are there any problems? > For example, the Realtek 8111 has pauses, which can cause lost data, > even with TCP. See [1] And the AX88179 silently corrupts data, > even with TCP. See [2] > axe(4) does *NOT* support AX88179. AX88179 is supported by axge(4). Last time I tried axge(4) it showed poor performance with lots of RX errors. Enabling flow control slightly mitigates it though. If you see corrupted data with axge(4), try disabling all checksum offloading features and test it again. If you still see the same data corruption without checksum offloading it surely indicates data handling issue of the driver. > Question 4: > > I thought you don't have any working network devices on your box so > > I recommended to use USB based ethernet controller(i.e. axe(4)) to > > get working network on the box. > > The axe(4) man page lists several chips. Do any of these actually work > correctly with FreeBSD? Yes. > I found that the AX88179 silently corrupts data > unless the data rate is very slow. For details, see [2] > > Question 5: > > Unfortunately I didn't get any answers/hints from Broadcom. > > Still nothing from Broadcom? They claim it works with FreeBSD, > but they will not assist? Broadcom used to support FreeBSD for a long time. They donated engineering samples for driver development and answered specific technical questions and submitted support code for new controllers before the controllers are available on market. > Does FreeBSD have anyone who is good at > diplomaticly rattling cages? > > [1] See the "Realtek re(4) driver" thread on hackers@ > [2] See "AX88179 USB-to-Ethernet is slow and silently corrupts data" > on hackers@, drivers@, usb@, net@ From owner-freebsd-hackers@freebsd.org Tue Apr 24 05:45:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63626FBC1F6 for ; Tue, 24 Apr 2018 05:45:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D48BF78FB3 for ; Tue, 24 Apr 2018 05:45:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pg0-x234.google.com with SMTP id e9so10021033pgr.7 for ; Mon, 23 Apr 2018 22:45:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=IkICy7aMTN3/ZKSXc+zfRT6FjDzO6fc/J82GaH1lars=; b=kYpUTjE4pKfi19WLG/bBfP0AlWrY7odp5+Y1zNI8rNBn0Qol5JJsowyrn2Cl5M+t3b lh78vyTJvFVzgHoLdAbBQQ9QrYasIwLjR+kM038Vb5xnxn0FCnO4DBH/EFDWnyff8GrU iKq7+DLWdkUATdqK/xYpW+8sMGZwFjEp9TbBQuhLrPS7FcCGiBlwXF2IKnoQtDIZ/rJG zwLfX34EqiQVn8eMBW7rgNNNSjXmToOY7sBfKrqIO1+2qqyiToVhwjO/UTijhuumPjim DsZPU7CyV3ckKT+yp4faojWM/Gv/t7vOv39otq9vTDScuQCQgn+45uWv2HzVWWJi4L+i l8YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=IkICy7aMTN3/ZKSXc+zfRT6FjDzO6fc/J82GaH1lars=; b=INup1HNu8dM5I+MO/LEvRy7Eonr8qiYe9fWh4cCW1LKtzE3v6Qp6ddY2vSRtguqSoc 7Giu1VFgOV3wnAr4mOLAWvJnc6a56RhWdcA+Epq2DkBhP2Mpy7lUvjGUE1kg1PqewlFq uH2bwS3RNIPm53OfRkWPkIgxzGk9pKnGzIurvj5qPFkIElFFIH5OJpx/C65SDR+l0pfo K7P6IfqFVAAc4JSe+mjlgKI081faCilcj7BaaJvvRhg2u1UaTaUC26T5H+yJGTULfQkX VH6L7xcA3mJtg7mBa0ce4MHIb1JsoQE7i9REyXaCwZ+fG2QAqEBcB+3bKQAtKIHg5ZWR 2SiA== X-Gm-Message-State: ALQs6tCeIlSbHLjwFPRL7KX6COVdmx0l/YwfGMzK1d96kGANi8dHqnlT BW/P3p44+O8g536iv8iFYVcjuA== X-Google-Smtp-Source: AIpwx4+7pzQflshksdbYMKlK31+0sArpmtDnY+HfClA5IAftkEP1EE2FJi4WkJy/RIInQbzAVu1SrQ== X-Received: by 10.98.7.152 with SMTP id 24mr22535940pfh.94.1524548707940; Mon, 23 Apr 2018 22:45:07 -0700 (PDT) Received: from localhost ([58.237.141.52]) by smtp.gmail.com with ESMTPSA id 86sm32290800pfh.93.2018.04.23.22.45.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 22:45:07 -0700 (PDT) From: YongHyeon PYUN X-Google-Original-From: "YongHyeon PYUN" Received: by localhost (sSMTP sendmail emulation); Tue, 24 Apr 2018 14:45:03 +0900 Date: Tue, 24 Apr 2018 14:45:03 +0900 To: Dieter BSD Cc: freebsd-hackers@freebsd.org Subject: Re: Realtek re(4) driver Message-ID: <20180424054503.GC3123@michelle.fasterthan.co.kr> Reply-To: pyunyh@gmail.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 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 05:45:09 -0000 On Sun, Apr 22, 2018 at 10:57:07PM -0700, Dieter BSD wrote: > With several days more data, the Realtek driver is slightly different > than the stock FreeBSD 10.3 driver, but it still fails a lot, with both > TCP and UDP. > [...] > My re run (1000baseT ) but the pauses happen even with > light traffic. You don't have to run them full blast with rcp/ftp/whatever > to get failures. > I guess benchmarks/netperf or benchmarks/iperf is better tool to measure performance of ethernet driver. rcp/ftp involves other IOs with network IO so you may measure performance of other subsystem. If you see intermittent pauses during the test, try enabling or disabling ethernet flow control of the controller. # Disable flowcontrol #ifconfig re0 media auto -mediaopt flow # Enable flowcontrol #ifconfig re0 media auto mediaopt flow [...] > rcp(1) to 8111F using Realtek driver > Both machines basically idle. > mtu=9000 on both ends but appears to be using 1500 anyway? Cached route may cache the MTU of the interface. You may have to down and re-up the interface to reflect the change. > netstat -w 1 -d -I re0 > > input re0 output > packets errs idrops bytes packets errs bytes colls drops > 5 0 0 330 6 0 755 0 0 > 4 0 0 264 4 0 564 0 0 > 5 0 0 331 5 0 630 0 0 > 17454 0 0 26176844 17453 0 1152264 0 0 > 67883 0 0 101023187 67880 0 4481248 0 0 > 52133 0 0 77141014 52140 0 3444580 0 0 > 72410 0 0 107980584 72409 0 4780384 0 0 > 80736 0 0 120645177 80735 0 5328810 0 0 > 71898 0 0 107298972 71899 0 4745634 0 0 > 14452 0 0 21510681 14475 0 955577 0 0 > 5 0 0 330 6 0 755 0 0 > 4 0 0 264 4 0 564 0 0 > 5 0 0 331 5 0 630 0 0 > 4 0 0 264 4 0 564 0 0 > 65323 0 0 97533279 65321 0 4311552 0 0 > 28383 0 0 42398766 28385 0 1873769 0 0 > 80759 0 0 120315366 80756 0 5330394 0 0 > 80992 0 0 120693553 80995 0 5345772 0 0 > 80932 0 0 120692488 80930 0 5341746 0 0 > 78905 0 0 117912275 78922 0 5209152 0 0 > 80158 0 0 119592452 80159 0 5290728 0 0 These counters are maintained in driver but it's not from MAC of the controller. So you can't tell how much RX packets were dropped before driver sees them. There is an undocumented sysctl variable which reads H/W MAC counters and output them on console. #sysctl dev.re.0.stats=1 From owner-freebsd-hackers@freebsd.org Tue Apr 24 08:35:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5ABA7FC0131 for ; Tue, 24 Apr 2018 08:35:57 +0000 (UTC) (envelope-from joerg@bec.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EA4BB816EC for ; Tue, 24 Apr 2018 08:35:56 +0000 (UTC) (envelope-from joerg@bec.de) Received: by mailman.ysv.freebsd.org (Postfix) id A8D6EFC012F; Tue, 24 Apr 2018 08:35:56 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96A91FC012E; Tue, 24 Apr 2018 08:35:56 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 107B3816C4; Tue, 24 Apr 2018 08:35:55 +0000 (UTC) (envelope-from joerg@bec.de) X-Originating-IP: 87.153.207.125 Received: from britannica.bec.de (p5799CF7D.dip0.t-ipconnect.de [87.153.207.125]) (Authenticated sender: joerg@bec.de) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id E348960020; Tue, 24 Apr 2018 10:35:47 +0200 (CEST) Date: Tue, 24 Apr 2018 10:34:49 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org, hackers@freebsd.org Subject: Re: Realtek re(4) driver Message-ID: <20180424083449.GB11959@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <20180411121404.71a07fef@ernst.home> <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> <20180411104533.GC1134@albert.catwhisker.org> <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> User-Agent: Mutt/1.9.0 (2017-09-02) X-Spam-Level: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 08:35:57 -0000 On Wed, Apr 11, 2018 at 12:51:09PM +0200, Alex Dupre wrote: > David Wolfskill wrote: > >> I use a diskless workstation. With re driver provided by FreeBSD kernel > >> (9/10/11.x), system randomly crashed because ethernet driver stalls (and > >> datarate is always less than 300mbps). With official realtek driver > >> (v194.01), system now runs as expected (with datarate up to 1 Gbps). > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 > > Anyone interested in taking the bounty or contributing to it? Perhaps > the FreeBSD Foundation should jump in? A starting point would be: (1) what hardware offload features are enabled (2) whether a specific direction is the problem (3) correlate traffic on both ends, i.e. what packets are dropped "on the wire" The most likely cause of any problem here is a missing workaround for a hardware bug or Realtek deciding that some specific tuning is necessary for certain chips. It is nearly impossible to fix this kind of bugs without having access to the hardware and a way to reproduce it. Comparing with a working driver might be possible, but it is extremely tideous. Joerg From owner-freebsd-hackers@freebsd.org Tue Apr 24 13:55:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2DD3FA5456 for ; Tue, 24 Apr 2018 13:55:23 +0000 (UTC) (envelope-from sysadmin@alexdupre.com) Received: from lab.alexdupre.com (lab.alexdupre.com [93.151.207.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C480698A1 for ; Tue, 24 Apr 2018 13:55:22 +0000 (UTC) (envelope-from sysadmin@alexdupre.com) Received: (qmail 71154 invoked from network); 24 Apr 2018 13:48:38 -0000 Received: from 151-0-207-195.ip282.fastwebnet.it (HELO ale.bitgold.com) (sysadmin@alexdupre.com@151.0.207.195) by lab.alexdupre.com with ESMTPSA; 24 Apr 2018 13:48:38 -0000 Subject: Re: Realtek re(4) driver To: freebsd-hackers@freebsd.org, hackers@freebsd.org References: <20180411121404.71a07fef@ernst.home> <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> <20180411104533.GC1134@albert.catwhisker.org> <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> <20180424083449.GB11959@britannica.bec.de> From: Alex Dupre Message-ID: <723a1947-5258-9654-2d1b-5b2ff29aecb8@alexdupre.com> Date: Tue, 24 Apr 2018 15:48:37 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180424083449.GB11959@britannica.bec.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 24 Apr 2018 16:25:22 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 13:55:23 -0000 Joerg Sonnenberger wrote: > The most likely cause of any problem here is a missing workaround for a > hardware bug or Realtek deciding that some specific tuning is necessary > for certain chips. It is nearly impossible to fix this kind of bugs > without having access to the hardware and a way to reproduce it. > Comparing with a working driver might be possible, but it is extremely > tideous. I've just setup two machines with re interfaces (one onboard and one with an external pci-ex card), connected point to point, but I was unable to reproduce the issue. I can easily reproduce it on another server, but that's a semi-production one, so I can do limited testing (ie replace the if_re.ko kernel module, reboot, and do something for a few minutes, then I have to revert to the working kernel module). -- Alex Dupre From owner-freebsd-hackers@freebsd.org Tue Apr 24 16:48:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B88D2FABA8E for ; Tue, 24 Apr 2018 16:48:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F91C74A68 for ; Tue, 24 Apr 2018 16:48:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id u62-v6so15914038ita.5 for ; Tue, 24 Apr 2018 09:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5+kaMjY3ouzM5ewPN7p6awyzMrDidkiHeiw075ZN7Dg=; b=zNhSS2p6WiDpCvg7eKHrgZkmpYoGpdW4Qc1TJS0wtZaSJupPgh4Zi786a1Nle3fM+p HF7gAaQo91xzuIv83cZKRfVT2pC/INrBUzkD/rhK4Tg6qPwDoQCrC8O9wyoLWL8LkZ7R nituwQTiCEA6FaOB38O/yZnTDcBLWOJhP7qJnlr1DlSUzLZF6Z8tg115Dkcu/Fx2NjK3 OI0hOzVErO7l/fANxWcaKoEKOoRQKTpQHXrE9YrwgSa75fTtIS2o4LCEt/z8YpSl+Z5O PXQuXORyQsaykjt6SOyCaSIvfYwGIzBt8hfq6tMg0qAZtEUaV+hzFdtvLAHHnzZ4cLMY qylw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5+kaMjY3ouzM5ewPN7p6awyzMrDidkiHeiw075ZN7Dg=; b=RgTHOrQGHwk7OKdelahIwnDkxamfGX+3lwO9zcu0s8quKt/tL/KvSNxEkE7e1b3N6W /TC6YbgfdjFujQg6SHQQ9rfB19axJ9Ctlc6/4fJWpgRQLpNKKohzpN7DmPJvau47wSaU BrVTWruYGdUQVuW9an4UA6FDAE2svhtduGoYdvfS+ZlvoIy93h0Qq96oAVfmEgAR7u6v kWU8ArihWpHWG+W6LkksGsEe5vBwGa/Tp5Lrk4hXt/juXY3cDdlP9JpwgOu/UPKQppLB nr3eoDLv98trL++qoSi/klV519O/j/beH09xQEOkKbr+pN4HgeqgvDYHvYmHccHpZsGx 2hVg== X-Gm-Message-State: ALQs6tA2is2Vev8EL0u/q4IvP31NEtK5qYQVjpEfEh9q/GfYfRmWzNxm shKMz5nxNcgAsz5OedL17Lc4cwTdT6RcwnHJSAebcw== X-Google-Smtp-Source: AB8JxZoMDMI0htkxbD1nbhhdJ5RtB6wJlzUTndgbLQpO282uYnFmHgEJ3rlEN/rxVzTDUPWxa74Mm2Cob5XZAyZ4r3s= X-Received: by 2002:a24:1fc7:: with SMTP id d190-v6mr18186809itd.57.1524588533227; Tue, 24 Apr 2018 09:48:53 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:a604:0:0:0:0:0 with HTTP; Tue, 24 Apr 2018 09:48:51 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <723a1947-5258-9654-2d1b-5b2ff29aecb8@alexdupre.com> References: <20180411121404.71a07fef@ernst.home> <8919d821-2200-a2aa-87c3-bcad16bc75fb@systella.fr> <20180411104533.GC1134@albert.catwhisker.org> <17a3825a-03f4-0760-8d4f-1ce28a48cfdd@FreeBSD.org> <20180424083449.GB11959@britannica.bec.de> <723a1947-5258-9654-2d1b-5b2ff29aecb8@alexdupre.com> From: Warner Losh Date: Tue, 24 Apr 2018 10:48:51 -0600 X-Google-Sender-Auth: S4BnCsAOsBtGB2RMEnFbO2nWvUs Message-ID: Subject: Re: Realtek re(4) driver To: Alex Dupre Cc: "freebsd-hackers@freebsd.org" , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 16:48:55 -0000 On Tue, Apr 24, 2018 at 7:48 AM, Alex Dupre wrote: > Joerg Sonnenberger wrote: > > The most likely cause of any problem here is a missing workaround for a > > hardware bug or Realtek deciding that some specific tuning is necessary > > for certain chips. It is nearly impossible to fix this kind of bugs > > without having access to the hardware and a way to reproduce it. > > Comparing with a working driver might be possible, but it is extremely > > tideous. > > I've just setup two machines with re interfaces (one onboard and one > with an external pci-ex card), connected point to point, but I was > unable to reproduce the issue. I can easily reproduce it on another > server, but that's a semi-production one, so I can do limited testing > (ie replace the if_re.ko kernel module, reboot, and do something for a > few minutes, then I have to revert to the working kernel module). > The rl/re cards have some code in them to cope with cable length to the hub, since on the older cards this can greatly increase reliability. Perhaps there's signal issue here? Also, the re drivers are known to have some revs that have hardware offload features, but that said features don't work. Ideally, if you had a completely reproducible scenario you could turn off all the hardware offload and see if that fixes the problem. Warner From owner-freebsd-hackers@freebsd.org Thu Apr 26 20:19:39 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68EF8FB746E for ; Thu, 26 Apr 2018 20:19:39 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA64478479 for ; Thu, 26 Apr 2018 20:19:38 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f47.google.com with SMTP id m18-v6so15301566lfb.0 for ; Thu, 26 Apr 2018 13:19:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:resent-from:resent-to:resent-date :resent-message-id:resent-user-agent:to:from:subject:openpgp :message-id:date:user-agent:mime-version:content-language :content-transfer-encoding; bh=mQjAbz4b/NxuVh1zRWVH0rJbYsupxA3YxLvt4MLHuK8=; b=mCya49pTnyrxtH0qvGWFWGUkuyI/2XKNJwsa/LCKVdEfTY7FzXSmQr86Ho1N7mEvCi x0sbpd1KPOnYmtx2BgF6ebyZK1X6CZA4WqBGrvBB9YpTpg3sVcGL6S6A1TyFjxIybPHp xLTz8FwQQnGDI4IaH0bNdUwTfYY2WPusKP6OBTBaC1/aPrjKfJyX/4K4V+tI6zh7GmcC H5dwOiHFV9vLXyidBq3mU2jMuC5vEmnUzYiYNF9yMALgqZwrh/GBgtTz7qAADZOGsTx4 oJdsdumXwp4JNrFRVHVXu7+lyfRdoHvEBTuz1GybF8oSQkgY/JsXxXUniHebrSi/icWr g3Tw== X-Gm-Message-State: ALQs6tDSilCz819K87TQKTrivAezUncoJibYrhcs+BeZLOlt5z2zNGXb y97khyxoShNZUSWEYqd6jQyZg5CB X-Google-Smtp-Source: AB8JxZptNehyQUUS31SAbupQgX2hnGp+KUrUvkb5GxAWXPiwmI0ZOh0aO4wMh8Z3zOYR2ThvJAV0EQ== X-Received: by 10.46.158.85 with SMTP id g21mr114558ljk.30.1524773976983; Thu, 26 Apr 2018 13:19:36 -0700 (PDT) Received: from [10.141.214.5] ([78.111.187.12]) by smtp.googlemail.com with ESMTPSA id z4sm293534lji.14.2018.04.26.13.19.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Apr 2018 13:19:36 -0700 (PDT) Resent-From: Andriy Gapon Resent-To: "freebsd-hackers@freebsd.org" Resent-Date: Thu, 26 Apr 2018 23:19:27 +0300 Resent-Message-ID: <5a296ca4-ac55-c4c8-186b-cc4a72ade651@FreeBSD.org> Resent-User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 To: "freebsd-hackers@freebsd.org" From: Andriy Gapon Subject: suspend to ram and AP cache Openpgp: preference=signencrypt Message-ID: Date: Thu, 26 Apr 2018 23:07:20 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2018 20:19:39 -0000 I am playing with some changes to suspend / resume code and I see some behavior that I didn't quite expect. Here is a sketch of the code. AP: - savectx - wbinvd - atomic_add_rel_int(&suspend_count, 1) // lock add $1, addr - while (1) cpu_spinwait() BSP: - while (suspend_count < expect_count) cpu_spinwait() - wbinvd - enter ACPI suspend What I see is that after the resume suspend_count may have a value different from what it was before the suspend (expect_count). In fact, it's just zero in all tests I have done so far. If I move wbinvd to a position just after the suspend_count increment, then the post-resume value is consistently the expected value. It appears that the changes to suspend_count performed by the APs may never make it to the main memory unless the caches of the APs are flushed afterwards. This is the part that I find surprising. I will double-check the code and the test to be more confident that what I described is what actually happens. The hardware is AMD and the architecture is amd64. I understand that on modern hardware even lock-ed stores do not have to go to the main memory immediately as they can be handled by cache coherency protocols. For AMD it seems to be MOESI. I guess that one of the AP caches Owns the cached (dirty) value and the BSP has it only in the Shared mode, so the cache flush on the BSP did nothing to store the cached value and the owning AP didn't get enough time to do the store. Just wanted to share this and get some feedback on whether the theory is plausible. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Fri Apr 27 07:15:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9A2BFC2B70 for ; Fri, 27 Apr 2018 07:15:09 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F30F87461 for ; Fri, 27 Apr 2018 07:15:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id BxasfrDtMuYopBxaufPnKg; Fri, 27 Apr 2018 01:15:01 -0600 X-Authority-Analysis: v=2.3 cv=GopsBH9C c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=kj9zAlcOel0A:10 a=Kd1tUaAdevIA:10 a=DSHT9BU3AAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=DH_9fKfAI4jOcsW4WfsA:9 a=CjuIK1q_8ugA:10 a=l1v8eG2oEcoA:10 a=5VDFy3MQIaIA:10 a=8ljxv5-TN0tg3ptMfEC3:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 2328D251 for ; Fri, 27 Apr 2018 00:14:50 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id w3R7EoZE060787 for ; Fri, 27 Apr 2018 00:14:50 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id w3R7EoN1060779 for ; Fri, 27 Apr 2018 00:14:50 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201804270714.w3R7EoN1060779@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: "freebsd-hackers@freebsd.org" Subject: zpool status see: URLs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Apr 2018 00:14:50 -0700 X-CMAE-Envelope: MS4wfHO1vs2bt89ijOdLJMPuT24RM7qdH3a33ztgGjrQxbNvkd3aOI4BPK3kyBzgRZ7cjAIbtjm06v6ofbco78AD9PjU3mb0SOYCArJAWvp/Pky5w802saRX jCsTQZmF/h0KUdMAVFsVR1GbPR6qWYzETM95i37PozB8mas7Wsbn0vSw6MlG6AlOWvMS+i8dBCv1Ng== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 07:15:09 -0000 Hi, Our zpool status "see:" URLs have an illumos.org URL, e.g. http://illumos.org/msg/ZFS-8000-8A. Should we either a) have our own URL or b) possibly back the pages up just in case of the worst case scenario? -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Fri Apr 27 18:26:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7A63FAF25A for ; Fri, 27 Apr 2018 18:26:34 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from knopi.disroot.org (knopi.disroot.org [178.21.23.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5AB2579C8F for ; Fri, 27 Apr 2018 18:26:34 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 391992E075 for ; Fri, 27 Apr 2018 20:26:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1524853593; bh=4utKKidajOrQwSNhp8lZ3v6g3XnJ1v3wJsJWv120Kc8=; h=Subject:To:References:From:Date:In-Reply-To; b=Rx/JS1X+khzfPx3kB6DYKj05vc59TvlqBXeEkArUsajhqMJ0XEZQPEWcvNtSzzmqG 8WjqpUL1RLzV66/vR41ok+8o4XWJzlUB50r74tquBsgEJCLnJnahlZ1n4Owl5ap+kf Ut/9/EsdfE5VUbSGpZXCoxsL6SXed3ZlyyK0Jaun6/RbnUQK4f9EkpSFuY9ca66Ixp D6xKuGtDV2JuDl0cEYanoQgFq7KRtpls3mYikMWzyZ+d0dOPgYQ4+J+S9EnmxZLB6U NjgJ0Cs/Q6vbHFmU/AgbvbWpdqmphvWcg6wxd7Makx3kNJ1cF7HykryHUVUIdVFvOF DzqnEYTbjM9nw== X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (mail01.disroot.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPIqDcpB8DOQ for ; Fri, 27 Apr 2018 20:26:31 +0200 (CEST) Subject: Re: Broadcom 5719 Ethernet - Does it work yet? DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1524853591; bh=4utKKidajOrQwSNhp8lZ3v6g3XnJ1v3wJsJWv120Kc8=; h=Subject:To:References:From:Date:In-Reply-To; b=v35fKxJZ2kzmebumLroS8XUPcbdE42SZvN0WdPnoDRnxlE+0JNph+OCbcCTpnJlEn gNu9fbXtA6x+6iG7uu8E9wBrPUj5Te2tZc+WwvxdlX1vt46UnuT/jMC/1EZokE805K OiYl9TP4PsjaqCtLPtceMpU3Gd78H7PJ8UFMseOlnoA3h4a6s5jvfBm+eSP7ELUGiX Oz3S0Xp9U0U2rajY5zcd1tIu1u7HDxKSkwOtqC/8GfKp1UeFFrIUF6WF0qXz6Q+o2M e3DSDDFa5uPhFa3wCxsiirM1VGdqDuFiPBJFulF5dC40qmDhTrv/3nBsNR2snbhTYq IMZWVfJ/S55mw== To: freebsd-hackers@freebsd.org References: From: "Peter G." Message-ID: <0640b50d-6a52-1da6-4006-6db4ec7c8b74@disroot.org> Date: Fri, 27 Apr 2018 20:26:21 +0200 Mime-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2018 18:26:35 -0000 On 23/04/2018 08:01, Dieter BSD wrote: > Question 1: It appears that there were/are problems with both Dell > cards and HP cards. Is there something special about these cards > that could keep FreeBSD from working with them? Do they need to be > in Dell/HP systems or would they work in a vanilla machine? > (I'm thinking of getting one for a vanilla machine but only if it works.) > The 5719 and 5720 are the same except for 4 ports vs 2 ports, right? I have a few R-series Dell servers of the 12th. They all come with onboard 5720. Ethernet works with bge(4), generic settings. Running 11.1-RELEASE on all those systems. "works" means here "they can run, sure", but long term stability is, from my experience, let's say, less than ideal. I've had one server losing network already twice within 3 months with polling, and another losing network once, for no apparent reason, no polling. Already replaced the first one with intel i350-t2. The other one is still running 5720, to be replaced with prolly i210. If you want to buy new, don't. Get Intel i350 or i210 instead. Been running i350-t2 on another system under constant high load, no problems for over a year now. -- PG From owner-freebsd-hackers@freebsd.org Sat Apr 28 02:40:20 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB7D5FBA624; Sat, 28 Apr 2018 02:40:20 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59C60801D1; Sat, 28 Apr 2018 02:40:20 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-it0-x244.google.com with SMTP id f6-v6so4181801ita.2; Fri, 27 Apr 2018 19:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=le5T0bXDDAZZsxTeYCw5GH+GVdvtfj8A8elO+5HagWw=; b=n4wZeTzyM5/e70Md3D27ftwNXXt9jHTiAUBZAWYVtfquaAAIgiuFAH4Nix53UKydpY u/rHOCyhxH5S06DgWzv3dek8X9xCk5+ckpmkqy+qnPrevKwOIHkZ+riw3hqUTrnCYPq2 8p8jfqjFanFW7ngVGIHbDpOJ4rtFWV2bN+j3su9YZXXT/dNRx88XEOYhW79EiGEa3Yw5 8GMvdkEcR2b/8eIgmnpZGtuzrdplwhR7iS1rDNaMt3gTQabpNVsk6q7kGYsooleIZ+3n AGT/fjAu7rVloYIGHCORfYSrkcuhfJiccBpGwY0IE5ekYC7aY6pyrhVPFKDh32Q1p5K3 KtHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=le5T0bXDDAZZsxTeYCw5GH+GVdvtfj8A8elO+5HagWw=; b=p/pDF9CviblF8rKF1RHwBWfaZexcbt2PHDVlmZSczRAcuCQOM7I3+1CL/ew94BLSu6 y/rQi8TTlGOHmwOHaPSdihyXrvtCT9PzzTK1FYCr95KJiVQDFZ1zzdDlb/v04BWRQNz2 41vJbYFw0Uhl72coeARH8uVx3/S1T/0ld8JUzmndwfluNobVL29fa+kJSrByZv7lc8eI O4F66vv7ny0lJp5cLzpE9KwRqKJHt1/2wuxAooFPaKOepbTYtBhmiYUuMb5cg8CbKoAw o/A2PVZPlYUSU1OozpgjeRL49bdwwiekrCHMHn+JBKsEWqdJIPrFMsC/mm92WLLmzefx CPkA== X-Gm-Message-State: ALQs6tDN4ja0mpW2mSHhTYVVSleiTdwZAIHNX4xaHAB3ryyt1GYFKWwz hB3uKAEI0x2cT1+a4D/kSuUVX7gffWinFyVPRnJbZg== X-Google-Smtp-Source: AB8JxZqmVeBWmtXqZG/5ZHUcb/y8ueP4fUcnyhLRlLpIO1nNlDSrYBPeji6IaC6K3F0Fe6Y9kjwt2/lGG9oFGWuupvQ= X-Received: by 2002:a24:2c52:: with SMTP id i79-v6mr4611525iti.101.1524883219326; Fri, 27 Apr 2018 19:40:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:8d6a:0:0:0:0:0 with HTTP; Fri, 27 Apr 2018 19:39:38 -0700 (PDT) From: grarpamp Date: Fri, 27 Apr 2018 22:39:38 -0400 Message-ID: Subject: Exploit Lecture: Writing FreeBSD Malware To: freebsd-security@freebsd.org Cc: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sat, 28 Apr 2018 10:33:50 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 02:40:21 -0000 https://www.youtube.com/watch?v=bT_k06Xg-BE Without exploit mitigations and with an insecure-by-default design, writing malware for FreeBSD is a fun task, taking us back to 1999-era Linux exploit authorship. Several members of FreeBSD's development team have claimed that Capsicum, a capabilities/sandboxing framework, prevents exploitation of applications. Our in-depth analysis of the topics below will show that in order to be effective, applying Capsicum to existing complex codebases lends itself to wrapper-style sandboxing. Wrapper-style sandbox is a technique whereby privileged operations get wrapped and passed to a segregated process, which performs the operation on behalf of the capsicumized process. With a new libhijack payload, we will demonstrate that wrapper-style sandboxing requires ASLR and CFI for effectiveness. FreeBSD supports neither ASLR nor CFI. Tying into the wrapper-style Capsicum defeat, we'll talk about advances being made with libhijack, a tool announced at Thotcon 0x4. The payload developed in the Capsicum discussion will be used with libhijack, thus making it easy to extend. We will also learn the Mandatory Access Control (MAC) framework in FreeBSD. The MAC framework places hooks into several key places in the kernel. We'll learn how to abuse the MAC framework for writing efficient rootkits. Attendees of this presentation should walk away with the knowledge to skillfully and artfully write offensive code targeting both the FreeBSD userland and the kernel. https://twitter.com/lattera/status/989602709950029824 Shawn Webb is a cofounder of HardenedBSD, a hardened downstream distribution of FreeBSD. With over a decade in infosec, he dabbles in both the offensive and defensive aspects of the industry. On the advisory board for Emerald Onion, Shawn believes in a more free and open Internet. His whole house is wired for Tor. Getting on the Tor network is only a network jack away! https://www.youtube.com/user/CarolinaConVideos/videos CarolinaCon was started in 2005 and has been held every year since. With each passing year the conference continues to grow and attract more attendees and speakers. As has always been the case, CarolinaCon is put together and run by an all-volunteer staff. CarolinaCon is proudly brought to you by "The CarolinaCon Group". The CarolinaCon Group is a non-profit organization registered in the state of NC, dedicated to educating the local and global communities about technology, information/network/computer security, and information rights. The CarolinaCon Group is also closely associated with various 2600 chapters across NC, SC, TN, VA, LA, DC, GA, PA and NY. Many of the volunteers who help develop and deliver CarolinaCon come from those chapters. From owner-freebsd-hackers@freebsd.org Sat Apr 28 12:54:02 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 997A0FAE55B; Sat, 28 Apr 2018 12:54:02 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from knopi.disroot.org (knopi.disroot.org [178.21.23.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E5857C627; Sat, 28 Apr 2018 12:54:01 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id CEE362E0C5; Sat, 28 Apr 2018 14:53:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1524920039; bh=Uwo5uSvv3X5V8rx6h9WYGVNmosULzlNxiPKK/XFB6+Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=LseFT+ncQ7sKoYtUdyIJf2StSysgp9qLUZky2gMlpAhNAmvSKKIcKpTH8CYbuQpDS V387bALzt3E+/P1IwH3L03T1EvQFu7BO7A1RPDyG6WXXXWaCbF4FT42tbYochp133J lqETQvBTE3N0rHuYLpLRFITJDMVKCvkhHy+pu6jwd9PyAy0UhijVh/PGo9lb8zdYte k6mMY7PmWAbVPgnsWO0GdSoAHHsRNksbQGTEY86jHFqUGTJ/7hyvB7VAeSfuTHFubu V1pdHrCH8iUL9OBctdPwQyTiDGTUKl4JBeicrs1nKI4rzZF+ppECOuyyIZGctbcktk 0JQWVK/EtKldg== X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (mail01.disroot.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npEAgYHzpcZE; Sat, 28 Apr 2018 14:53:57 +0200 (CEST) Subject: Re: Exploit Lecture: Writing FreeBSD Malware DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1524920037; bh=Uwo5uSvv3X5V8rx6h9WYGVNmosULzlNxiPKK/XFB6+Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=OvJhP1GCfDWMcqwEO2LXpTLAI6/fhzi2Lz/vDtQ6GIT0ieP20lhiVYZGMMEvN8LEp VgyqiD3ZD5j1eQWU2mevBOOSpTLMjqNXYwULyNJkVXhAkEPnOg3EbA62oFLZLIlvr0 q7X1WDqjbA8/hYz6QGxbr01spGizR8chsM3x4+AN5uA8ruvWME4vTLBScLw7NZeBTe Vm8vDdF70tPDrW41HNZDVP+Bz0N4YRsaVz0xYGVAAnXGGX1eqZVFy2cDDffurbxfQ7 mIxCf4QukhcqrW34w4yce8h0rdu7SrFeOfgrdukD2Ish4cQ1gRIrX5zKa0eJNanmDL Gq7F7xxPAcSLQ== To: grarpamp@gmail.com, freebsd-security@freebsd.org Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org References: From: "Peter G." Message-ID: Date: Sat, 28 Apr 2018 14:53:46 +0200 Mime-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 12:54:02 -0000 Webb, next time when talking to any audience, remove your fucking hat. That's basic human courtesy. -- PG On 28/04/2018 04:39, grarpamp wrote: > https://www.youtube.com/watch?v=bT_k06Xg-BE > > Without exploit mitigations and with an insecure-by-default design, > writing malware for FreeBSD is a fun task, taking us back to 1999-era > Linux exploit authorship. Several members of FreeBSD's development > team have claimed that Capsicum, a capabilities/sandboxing framework, > prevents exploitation of applications. Our in-depth analysis of the > topics below will show that in order to be effective, applying > Capsicum to existing complex codebases lends itself to wrapper-style > sandboxing. Wrapper-style sandbox is a technique whereby privileged > operations get wrapped and passed to a segregated process, which > performs the operation on behalf of the capsicumized process. With a > new libhijack payload, we will demonstrate that wrapper-style > sandboxing requires ASLR and CFI for effectiveness. FreeBSD supports > neither ASLR nor CFI. Tying into the wrapper-style Capsicum defeat, > we'll talk about advances being made with libhijack, a tool announced > at Thotcon 0x4. The payload developed in the Capsicum discussion will > be used with libhijack, thus making it easy to extend. We will also > learn the Mandatory Access Control (MAC) framework in FreeBSD. The MAC > framework places hooks into several key places in the kernel. We'll > learn how to abuse the MAC framework for writing efficient rootkits. > Attendees of this presentation should walk away with the knowledge to > skillfully and artfully write offensive code targeting both the > FreeBSD userland and the kernel. > > https://twitter.com/lattera/status/989602709950029824 > > Shawn Webb is a cofounder of HardenedBSD, a hardened downstream > distribution of FreeBSD. With over a decade in infosec, he dabbles in > both the offensive and defensive aspects of the industry. On the > advisory board for Emerald Onion, Shawn believes in a more free and > open Internet. His whole house is wired for Tor. Getting on the Tor > network is only a network jack away! From owner-freebsd-hackers@freebsd.org Sat Apr 28 13:39:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61807FAF713; Sat, 28 Apr 2018 13:39:54 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from knopi.disroot.org (knopi.disroot.org [178.21.23.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7CBD877CA; Sat, 28 Apr 2018 13:39:53 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 390422E0EB; Sat, 28 Apr 2018 15:39:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1524922792; bh=iATcv+amWP0kdwBGj+iD29ylM0yfx14bRWMceIm2QPE=; h=To:From:Subject:Date; b=jv9zCI6oHJ5lI9XvR2mVKzFlgp/VXroeit/DvwgELOY/GkvfVs0aCVrdBkz/aqBMc FrLoe9ho4+Iw2DWS2QShMLad5vRxnKz668radXAUsi+b6u48mpyW56Svc7YtNBQldY J8eEDRD/ZTfduuWWKYJLdm/HM+T2PibhVciJonVpG3lB7C19etG4JOPpMG9basUAfr XcPOMXxF7Tl+eUnlKkzV9zDFSi3wHUHk39lnVotB+W+V3i0r03QdhnDVd9gJ3A8flk c9rdEJk3sVC3girhOSiHdYiOQd/l0FufedG53Vd4ldFr/v9EuiSg/nH2kr0SkesL56 ikx0eVlfcHG/A== X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (mail01.disroot.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kitWTG6r0Qm; Sat, 28 Apr 2018 15:39:50 +0200 (CEST) To: freebsd-amd64@freebsd.org, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1524922790; bh=iATcv+amWP0kdwBGj+iD29ylM0yfx14bRWMceIm2QPE=; h=To:From:Subject:Date; b=RUamFca7khtnVqIsxqDWP7pZFXxDgKxtj/PZ+c1mMeky2hMSV4rIxbT9hFjAdt1ZV C9WDICeFrSum27b5rQa+MhruDhfXQ29XLEUxpClvxUY+YHPeqLvs3ei/Is8Hrs+QVk AGG0gTz08pdh6VA45vMzyBiEpneNZDcwirT4KXrS9QgzBy3asCIaEPXI5CLimnKCQw 9ZWzxLU8a9QJAx92YxmYzCZzpaMqR7poVV8ccSzmRZzmPuiMdk+nea7xs5x6zbekBE PAPYna9Bc5bt6qiFcc4fQP7MiYlG9f4CQ3PykEeyVWakDrebxIdT5/cnsM/vrFXzv8 oNJv98aKl4vgQ== From: "Peter G." Subject: Can we please finally solve Dell's racadm for FreeBSD? Advice needed Message-ID: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> Date: Sat, 28 Apr 2018 15:39:39 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 13:39:54 -0000 Dear everybody, regarding: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201799 would somebody knowledgeable be kind enough to advice and/or help with bringing Dell racadm client/tools to FreeBSD? What is the problem with ipmi enumeration Dan mentioned on his commit? What is in the first place desired is local access to local hardware via standard racadm client. Local management is the "big kahuna" here. There were several attempts over the years, yet everything waned away without any solid results. Dell hardware is constantly mentioned on the lists or in the forums, so clearly many of us use it. I myself manage several Dell servers. The lack of local racadm for FreeBSD is daring. On my own and out of my pocket I will offer 50 EUR in Bitcoin to anybody who will solve the problem, i.e. provide a working racadm client which can access and manage local hardware. Of course anybody else is welcome to chime in. I am willing to put that in escrow with a trusted member of the community. Please let me know what to do. Many thanks! -- PG From owner-freebsd-hackers@freebsd.org Sat Apr 28 13:54:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D891FAFCEE for ; Sat, 28 Apr 2018 13:54:35 +0000 (UTC) (envelope-from nbari@codigo.io) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A76588A70D for ; Sat, 28 Apr 2018 13:54:34 +0000 (UTC) (envelope-from nbari@codigo.io) Received: by mail-wr0-x22a.google.com with SMTP id 94-v6so2878096wrf.5 for ; Sat, 28 Apr 2018 06:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codigo.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nuO8UwLub9DgmZv+m8er805wrQ2RUCZzFYAe+TiChwA=; b=LVNqyNNWrHkE7g22+b+pgaWh4+fqgt7J/voia+FwHBJMrCl/NYOSGkbmE/LmdmIx+0 e26UsnrdlVmjfOSswzwEIwCDvNx1fkdJzySjoLexfO0y9/Bf0c4adyU32/3gO2pOpZQc D+Nh5jksxnJ6K88W5toW4y6rLtrFqYR/Dnjg7wKhlJYMThf5h87QMI/s0x1NOHoZlwcF hIoDzYlsxIS/UAJYCX3niSUbZPjGVFdaFNhEE05Q+Qc1ob5fMniPQZ6e4p6mkmZECbHX mg3PJzimRhxZ1qPFG33Tu6yuLDMiojqbpAlHJLz8dutwxrsFCfEm3v0Yn9W0tDy0CzfS irYg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tequila.io; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nuO8UwLub9DgmZv+m8er805wrQ2RUCZzFYAe+TiChwA=; b=DzIjkrp295IJmKrP250mZdRUy0l2ARuUc/O8UdvhWpj8QRjIaiUIz+ntFJWR3tVToX D09kXiLesskZLy3FUmC8OKrzXWbUMkMCEiDrGQPpXjc1PjkWOXUY8VkizHt3zSAKa5SL MAaWV+3o0dkNiTO3Er4L/UHTyvE1E6kkjtga/3eD+L+qwLjvTLxOMQxNqdZ/EIztU0Yd P5692+KlXNVTkMSS44EP7zEYjunVDFioxEsa9NuHq4PeQ1Y//57FnWEnfyeMxRCoWDO4 N10zxWSdE22gd/9UksIDaCgEbWoWTc+qNGbuApoy7xnuvsVUbFv8Xf28TO8/8vBzZXp1 WtUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nuO8UwLub9DgmZv+m8er805wrQ2RUCZzFYAe+TiChwA=; b=ZxbWkSgs0Ahf6WIPihSnWDw7GCW1fS5IjXZmt727QYoxi28Wl4HhvTwjp1npNGoF/i SaBtyk3qzSkWDTC8rHlDJM1H0DscsVd1jRMYYhmd9v3df/37IM3N5B4BjueX6fJyyOKF 62KHlAnYSbHqaG1IEehI9fbH+fYmOsZoYTHAwwUBiUchVmn0/aqhoIcczvb2/Gh7dnq0 bpEbba+h45QMUfvV8LPGVd3vft9BROqX89wDlKYPI74riZ2noHA/wk23SXi5NfdHjBTZ 1tS52mfRb7Sd6LxiGlPNImexR/EL917YgFCJ1nSlHAc5Pqm7BXNVFKUmMudNu4FZpPZo 6Now== X-Gm-Message-State: ALQs6tDE9+cKOYU3FnSfJkyeuv4IE2N7hKb3Yg+t1LtoQJ9vtHcswDlY flZZ2QE2vy8xVd9LLTbgX3+KfUlSk+DTNO52QK++6Q== X-Google-Smtp-Source: AB8JxZr6hxhOoEeqIWPYcipfGkLjeF31Er4GAYTNdSc3mVsG1BvOJB7t+G1eRgkrX2bhAIQPvosU76rSfUOQMbvkL/I= X-Received: by 2002:adf:a3d7:: with SMTP id m23-v6mr4703136wrb.209.1524923673588; Sat, 28 Apr 2018 06:54:33 -0700 (PDT) MIME-Version: 1.0 Sender: nbari@codigo.io Received: by 10.223.176.5 with HTTP; Sat, 28 Apr 2018 06:54:33 -0700 (PDT) X-Originating-IP: [82.197.160.85] In-Reply-To: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> References: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> From: Nicolas Embriz Date: Sat, 28 Apr 2018 15:54:33 +0200 X-Google-Sender-Auth: j3spVbarGUQd5ZY_OwUZr4-qumo Message-ID: Subject: Re: Can we please finally solve Dell's racadm for FreeBSD? Advice needed To: "Peter G." Cc: freebsd-amd64@freebsd.org, FreeBSD Hackers , freebsd-hardware@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 13:54:35 -0000 Regarding this topic I have a Dell Power 2900 that I could donate for testing more in detail this issues. If interested please PM. Regards. On Sat, Apr 28, 2018 at 3:39 PM, Peter G. wrote: > Dear everybody, > > regarding: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201799 > > would somebody knowledgeable be kind enough to advice and/or help with > bringing Dell racadm client/tools to FreeBSD? What is the problem with > ipmi enumeration Dan mentioned on his commit? What is in the first place > desired is local access to local hardware via standard racadm client. > Local management is the "big kahuna" here. > > There were several attempts over the years, yet everything waned away > without any solid results. Dell hardware is constantly mentioned on the > lists or in the forums, so clearly many of us use it. I myself manage > several Dell servers. The lack of local racadm for FreeBSD is daring. > > On my own and out of my pocket I will offer 50 EUR in Bitcoin to anybody > who will solve the problem, i.e. provide a working racadm client which > can access and manage local hardware. Of course anybody else is welcome > to chime in. I am willing to put that in escrow with a trusted member of > the community. Please let me know what to do. > > Many thanks! > -- > PG > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Sat Apr 28 14:05:21 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1666FB01B8; Sat, 28 Apr 2018 14:05:21 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from relay.exonetric.net (relay0.exonetric.net [178.250.72.161]) by mx1.freebsd.org (Postfix) with ESMTP id 581068AD21; Sat, 28 Apr 2018 14:05:20 +0000 (UTC) (envelope-from mark@exonetric.com) Received: from [192.168.10.198] (90.69.187.81.in-addr.arpa [81.187.69.90]) by relay.exonetric.net (Postfix) with ESMTPSA id 7F2E42B10B; Sat, 28 Apr 2018 14:56:16 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Can we please finally solve Dell's racadm for FreeBSD? Advice needed From: Mark Blackman In-Reply-To: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> Date: Sat, 28 Apr 2018 14:56:14 +0100 Cc: freebsd-amd64@freebsd.org, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> To: "Peter G." X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 14:05:21 -0000 > On 28 Apr 2018, at 14:39, Peter G. wrote: >=20 > Dear everybody, >=20 > regarding: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D201799 >=20 > would somebody knowledgeable be kind enough to advice and/or help with > bringing Dell racadm client/tools to FreeBSD? What is the problem with > ipmi enumeration Dan mentioned on his commit? What is in the first = place > desired is local access to local hardware via standard racadm client. > Local management is the "big kahuna" here. >=20 > There were several attempts over the years, yet everything waned away > without any solid results. Dell hardware is constantly mentioned on = the > lists or in the forums, so clearly many of us use it. I myself manage > several Dell servers. The lack of local racadm for FreeBSD is daring. >=20 > On my own and out of my pocket I will offer 50 EUR in Bitcoin to = anybody > who will solve the problem, i.e. provide a working racadm client which > can access and manage local hardware. Of course anybody else is = welcome > to chime in. I am willing to put that in escrow with a trusted member = of > the community. Please let me know what to do. A kind offer, and much better than nothing. I think more like Nx1000 = Euros=20 cash would be a more realistic offer. Maybe a kickstarter campaign or = similar to fund it? If all the Dell server managers clubbed together, I bet they = could easily find that much. Alternately persuade the FreeBSD foundation to = put their focus behind it. - Mark= From owner-freebsd-hackers@freebsd.org Sat Apr 28 14:13:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD0DCFB0692; Sat, 28 Apr 2018 14:13:24 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from knopi.disroot.org (knopi.disroot.org [178.21.23.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2EFC48D9E5; Sat, 28 Apr 2018 14:13:23 +0000 (UTC) (envelope-from freebsd@disroot.org) Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 201EF2E075; Sat, 28 Apr 2018 16:13:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1524924802; bh=GM7lVvArRv/I63Q4hw5aY0MHRfhsKmN460ejXCBTqqk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=JJFloeGIwFEqpgjRdI0zi6+4mj+OAg1f1ahmqLW2vTKDAffJGuE63fXVP8hsnr1Cm 7lsiVMELO5raXZbq3oa0/dFUWv0tGiZ2+ciKEzF7pkrf303FcfkNlkNx0acj4gFIuJ TUv/cztBwO2zbyfTpnHAlE9JWHdgcuyhvd6tzYJmGS8wzlp0h/lzr8/on6wyMYbXx2 ogRgO5U5EDfX5dUJvtzzCzWk1jliu6PpNOCBvvxx54eLFOATJoVgujWjeVCwyZCoFU xuhwl63yCc4Y1kMqiiykQVo8kmkV3E5BXqI3p7xKiokTbuDqthaRb8594M74izdk1Z SHps6YMn9/btw== X-Virus-Scanned: Debian amavisd-new at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (mail01.disroot.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1424zeqgOKI; Sat, 28 Apr 2018 16:13:20 +0200 (CEST) Subject: Re: Can we please finally solve Dell's racadm for FreeBSD? Advice needed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1524924800; bh=GM7lVvArRv/I63Q4hw5aY0MHRfhsKmN460ejXCBTqqk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ldkJC4l7zs2yM2elkfm27NzXxlxTu5Bi0sJFza0rH5tcqfZZ4xN2jDpOYkGZjwrG9 oxvOQY9ooC33X+yTobsMbzWVGow060CRiei2iYJw5E+aoXm8nyIqSvzIkiPfo019I+ nKs7BW0ebv0PnqJhvEXk4KXXpybjfjKRP2yB20vVBr6N1im7TW+/8uU/F54msMqfEC Ri8To82M6sRTyAAEoV7/7Zvjh3r+XDRo2ycmyObDbKy7wkquF/JArjlZiBqZhD8hx0 Qf4wn/j4b3hPHU0qhmEijbV0cD61QKwQwHgR9yxb6dE0ZLbhBF6D8sdJD1fzNJr9Ng iLzeYmexUdkzw== To: mark@exonetric.com Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org, freebsd-hardware@freebsd.org References: <5eca3020-4b9c-dd43-8cf0-066d63a92521@disroot.org> From: "Peter G." Message-ID: <1c82e4d6-8fb6-3191-9e2f-ff7478c1284e@disroot.org> Date: Sat, 28 Apr 2018 16:13:09 +0200 Mime-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 14:13:24 -0000 On 28/04/2018 15:56, Mark Blackman wrote: >> On my own and out of my pocket I will offer 50 EUR in Bitcoin to anybody >> who will solve the problem, i.e. provide a working racadm client which >> can access and manage local hardware. Of course anybody else is welcome >> to chime in. I am willing to put that in escrow with a trusted member of >> the community. Please let me know what to do. > > A kind offer, and much better than nothing. I think more like Nx1000 Euros > cash would be a more realistic offer. Maybe a kickstarter campaign or similar > to fund it? If all the Dell server managers clubbed together, I bet they could > easily find that much. Alternately persuade the FreeBSD foundation to put their > focus behind it. I don't think this much exposure and/or funds is/are really needed here. The proposed port, especially after Dan's commits, is already functional. The local access is missing. I bet if anybody with knowledge what to do offers a bit of advice how to solve it, it will be solved in no time. I'd say this is more about know-how than funds. -- PG From owner-freebsd-hackers@freebsd.org Sat Apr 28 15:42:47 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 850BAFB27E2; Sat, 28 Apr 2018 15:42:47 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1523F7ABC0; Sat, 28 Apr 2018 15:42:47 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id CCD99178D6; Sat, 28 Apr 2018 17:42:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8TaGzT5ttP8; Sat, 28 Apr 2018 17:42:44 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 34938178D5; Sat, 28 Apr 2018 17:42:44 +0200 (CEST) To: FreeBSD Hackers , FreeBSD Filesystems From: Willem Jan Withagen Subject: Getting ZFS pools back. Message-ID: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> Date: Sat, 28 Apr 2018 17:42:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 15:42:47 -0000 Hi, I had this server crash on me, and first it just complained about not being able to boot because it could not find the guid. Now I cannot even import the pools any longer. Althoug zdb -l /dev/ada0 still gives me data that indicates that there should be a ZFS pool on that partition. Any suggestions on how to get the pools/data back online? Help would be highly appreciated, since restoring it from backups is going to quite some work. Thanx, --WjW From owner-freebsd-hackers@freebsd.org Sat Apr 28 18:43:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2A7FFB6A39; Sat, 28 Apr 2018 18:43:41 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 949DE827BB; Sat, 28 Apr 2018 18:43:41 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from [192.168.5.108] (pool-96-232-204-110.nycmny.fios.verizon.net [96.232.204.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 520D4335C5A; Sat, 28 Apr 2018 18:43:34 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Getting ZFS pools back. From: Richard Yao X-Mailer: iPad Mail (15E302) In-Reply-To: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> Date: Sat, 28 Apr 2018 14:43:31 -0400 Cc: FreeBSD Hackers , FreeBSD Filesystems Content-Transfer-Encoding: quoted-printable Message-Id: References: <5f836c79-b379-f066-689b-1645e393c5e9@digiware.nl> To: Willem Jan Withagen X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 18:43:42 -0000 What is the output of =E2=80=98zpool import=E2=80=98 with no arguments? > On Apr 28, 2018, at 11:42 AM, Willem Jan Withagen wrote:= >=20 >=20 > Hi, >=20 > I had this server crash on me, and first it just complained about not bein= g able to boot because it could not find the guid. >=20 > Now I cannot even import the pools any longer. > Althoug zdb -l /dev/ada0 still gives me data that indicates that there sho= uld be a ZFS pool on that partition. >=20 > Any suggestions on how to get the pools/data back online? >=20 > Help would be highly appreciated, since restoring it from backups is going= to quite some work. >=20 > Thanx, > --WjW > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"= From owner-freebsd-hackers@freebsd.org Sat Apr 28 20:11:51 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CAF6FB8EE2 for ; Sat, 28 Apr 2018 20:11:51 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8ED5476D12 for ; Sat, 28 Apr 2018 20:11:50 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: j2.v8dQVM1kqMRdAPs50y.kYJtc.a8xajQd1QNs_0ObeiIaqlUlb0tctzS3VCjQ BVdrFEEvXSsjxciJlksOoc0NP55a6z_ipHdlHhEqXp88V6ZJAZLgU95Xx67Wfr1hEekmb2.mIGou jrVG0n9uf2i99uUOamkpDO01NcXadyGnQvKXNcm0bNo8.VWxWk2socRbf0vaR77UmtnE8hw_OaU1 6Q.zpsrHfh.ANSR8AFuWyyAvuf.7tnJCAZGJLqI3QMxPQZCgoYKYsHGpfh0BQSlyy1if5JIxbnAf ZF8g0pYviPnLpPa6QA.RGdmCUaf2sCZ42IumUeq8PCn1mS4.om8Wlkj0CTkPIo49m7J0bQf6O7pU Uox7s8PLPAbYWYRsbPESFDM59YrwwRN.TCpzrj5NL8FVPU.pvY9iqIwae39vnab.X87o5PLPulOD mMR0SOpd1QlPwDmAzhYib8glRqxuQph5KknS1dYClqA9JW9ULZRc1cR3jbcsky1a3HG_Xb7dMPWY TmEmKFfaSDru.OjA.U.R8.uIPm4lSWRz0p_Kk6dis7Mc.e_qoty_WImvxLzvgdypRIerkbemz90S zlrdNeoLPN0NKS5lYjEDX4i9wV56R7hJ1OLLMeE4shwoappIQ.hYdCXPh7ZXnNLgaEjQbSCec Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Sat, 28 Apr 2018 20:11:44 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp417.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f8e257e151d9ef51f74ae6dda64803c7; Sat, 28 Apr 2018 20:11:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Interesting process hang on head -r333079 aarch64 (Pine64+ 2GB)? Message-Id: <77D17217-FC4C-40E6-BD1B-2E6ABE0458D8@yahoo.com> Date: Sat, 28 Apr 2018 13:11:39 -0700 To: freebsd-arm@freebsd.org, "freebsd-hackers@freebsd.org" X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2018 20:11:51 -0000 Using a new instance of top to watch and older one, the old one shows (no longer updating): up 0+13:47:14 09:58:51 and the new one shows for it: PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND . . . 834 root 1 20 0 13652K 1972K 0K select 3 2:21 = 0.00% top -CawSores =20 when the new one shows: up 0+16:56:14 13:07:51 So, over 3 hours later. I'll note that about 2 hours earlier it showed a larger RES figure, the = same figure the old top display shows: PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND . . . 834 root 1 20 0 13652K 2576K 0K select 3 2:21 = 0.00% top -CawSores (gstat -pd also tends to stop updating, but I use top as the example here.) For reference the old (non-updating) top instance shows itself as: PID USERNAME THR PRI NICE SIZE RES SWAP STATE C TIME = CPU COMMAND . . . 834 root 1 20 0 13652K 2576K 0K CPU3 3 2:21 = 0.33% top -CawSores The context is a Pine64+ 2GB building devel/llvm60 over the time, via poudriere-devel, 1 builder but allowing it to use all 4 cores. UFS context, not ZFS. devel/llvm60 started building 3:55:35 into the poudriere run and has been in process for many hours. The instances of top are via ssh logins over Ethernet. poudriere is running on the console. (No non-poudriere console messages during the poudriere run.) Typing Control-L to the ssh session for old instance of top will cause it to start updating again. (That is what I normally do when I notice the lack of updates.) # uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r333079M arm64 = aarch64 1200062 1200062 This is built as a non-debug build with symbols and explicitly causing -mcpu=3Dcortex-a53 : XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. ACFLAGS.arm64cpuid.S+=3D -mcpu=3Dcortex-a53+crypto ACFLAGS.aesv8-armx.S+=3D -mcpu=3Dcortex-a53+crypto ACFLAGS.ghashv8-armx.S+=3D -mcpu=3Dcortex-a53+crypto As for what vintage I'm building for /usr/ports : # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 468505 Last Changed Rev: 468505 But it is a large /usr/ports jump, from something like early January if I remember right. (FreeBSD was also from back then before I started this update sequence.) Context details (if you care): # svnlite status /usr/src | sort ? /usr/src/local_iperf3.sh ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/release/Makefile.vm M /usr/src/release/scripts/mk-vmimage.sh M /usr/src/release/tools/vmimage.subr M /usr/src/secure/lib/libcrypto/Makefile M /usr/src/stand/defs.mk M /usr/src/stand/powerpc/boot1.chrp/Makefile M /usr/src/stand/powerpc/kboot/Makefile M /usr/src/sys/arm64/arm64/identcpu.c M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c M /usr/src/sys/vm/uma_core.c M /usr/src/usr.bin/top/machine.c Most of the "M"s are non-aarch64 material. My GENERIC-*DBG's include the matching GENERIC and then override various debug-status points. Only powerpc family ones do somewhat more. # svnlite diff /usr/src/crypto/openssl/crypto/armcap.c Index: /usr/src/crypto/openssl/crypto/armcap.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/crypto/openssl/crypto/armcap.c (revision 333079) +++ /usr/src/crypto/openssl/crypto/armcap.c (working copy) @@ -137,7 +137,9 @@ } } else if (sigsetjmp(ill_jmp, 1) =3D=3D 0) { _armv7_neon_probe(); +#ifndef DISABLE_HACK_THAT_AVOIDS_NEON OPENSSL_armcap_P |=3D ARMV7_NEON; +#endif if (sigsetjmp(ill_jmp, 1) =3D=3D 0) { _armv8_pmull_probe(); OPENSSL_armcap_P |=3D ARMV8_PMULL | ARMV8_AES; # svnlite diff /usr/src/sys/arm64/arm64/identcpu.c Index: /usr/src/sys/arm64/arm64/identcpu.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/arm64/arm64/identcpu.c (revision 333079) +++ /usr/src/sys/arm64/arm64/identcpu.c (working copy) @@ -1109,6 +1109,9 @@ =20 /* Wake up the other CPUs */ atomic_store_rel_int(&ident_lock, 0); - __asm __volatile("sev" ::: "memory"); + __asm __volatile( + "dsb ish \n" + "sev \n" + ::: "memory"); } } # svnlite diff /usr/src/sys/kern/subr_pcpu.c Index: /usr/src/sys/kern/subr_pcpu.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/kern/subr_pcpu.c (revision 333079) +++ /usr/src/sys/kern/subr_pcpu.c (working copy) @@ -279,6 +279,8 @@ struct pcpu * pcpu_find(u_int cpuid) { +if (mp_ncpus =3D=3D 0 && cpuid =3D=3D 0) {} // HACK: This combination = is used in the late bootstrap +//else if (mp_ncpus <=3D cpuid) { panic("pcpu_find: cpuid too large"); = } // HACK =20 return (cpuid_to_pcpu[cpuid]); } (The above I've sometimes uncommented the else for powerpc family experiments.) # svnlite diff /usr/src/sys/vm/uma_core.c Index: /usr/src/sys/vm/uma_core.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/vm/uma_core.c (revision 333079) +++ /usr/src/sys/vm/uma_core.c (working copy) @@ -3441,7 +3441,7 @@ void uma_reclaim_wakeup(void) { - +printf("limit %lX, total %lX, needed %d\n", uma_kmem_limit, = uma_kmem_total, uma_reclaim_needed); if (atomic_fetchadd_int(&uma_reclaim_needed, 1) =3D=3D 0) wakeup(uma_reclaim); } I've seen the behavior with an unmodified top but I add a "K MaxObsUsed, " for swap normally: # svnlite diff /usr/src/usr.bin/top/machine.c Index: /usr/src/usr.bin/top/machine.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/usr.bin/top/machine.c (revision 333079) +++ /usr/src/usr.bin/top/machine.c (working copy) @@ -194,9 +194,9 @@ NULL }; =20 -int swap_stats[7]; +int swap_stats[8]; char *swapnames[] =3D { - "K Total, ", "K Used, ", "K Free, ", "% Inuse, ", "K In, ", "K = Out", + "K Total, ", "K Used, ", "K MaxObsUsed, ", "K Free, ", "% Inuse, = ", "K In, ", "K Out", NULL }; =20 @@ -550,14 +550,14 @@ =20 /* first interval */ if (swappgsin < 0) { - swap_stats[4] =3D 0; - swap_stats[5] =3D 0; + swap_stats[4+1] =3D 0; + swap_stats[5+1] =3D 0; } =20 /* compute differences between old and new swap = statistic */ else { - swap_stats[4] =3D pagetok(((nspgsin - = swappgsin))); - swap_stats[5] =3D pagetok(((nspgsout - = swappgsout))); + swap_stats[4+1] =3D pagetok(((nspgsin - = swappgsin))); + swap_stats[5+1] =3D pagetok(((nspgsout - = swappgsout))); } =20 swappgsin =3D nspgsin; @@ -564,14 +564,16 @@ swappgsout =3D nspgsout; =20 /* call CPU heavy swapmode() only for changes */ - if (swap_stats[4] > 0 || swap_stats[5] > 0 || swap_delay = =3D=3D 0) { - swap_stats[3] =3D swapmode(&swapavail, = &swapfree); + if (swap_stats[4+1] > 0 || swap_stats[5+1] > 0 || = swap_delay =3D=3D 0) { + swap_stats[3+1] =3D swapmode(&swapavail, = &swapfree); swap_stats[0] =3D swapavail; swap_stats[1] =3D swapavail - swapfree; - swap_stats[2] =3D swapfree; + if (swap_stats[2+0]