From owner-freebsd-drivers@freebsd.org Tue Apr 10 22:50:10 2018 Return-Path: Delivered-To: freebsd-drivers@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 20BC4FA048A; Tue, 10 Apr 2018 22:50:10 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (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 AF2C173D02; Tue, 10 Apr 2018 22:50:09 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-io0-x243.google.com with SMTP id d7so264613ioc.11; Tue, 10 Apr 2018 15:50: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=+a3TTQwKZ1zs+Vcs/SHP+ZMoY6iHpHPUNUY7vuSWLjk=; b=LdtKmgsierLueQ17v+l+LY8FoO4k4sd0gRCOjFPmcDafJqeI6l3yIyGPocII+tkXyS lohoOXSYKz+3owy6hBZ+HYUFymXN4sFIC1BE3eqBWmZqmU1vnkm5+KcotB2/WJOZbh/r GHvz3ZNgcBtdemoOffBp2C94/GJyDOJ86hp3EmoNOl3Z8uSFrv3HfkDfXkjpon9vcoeM szxnUGKIVA6SSilRq4VtEbkQK2v8dPUHWGbQG0p+fKi3GS211wK1qj1Fsl605qoUywtz gTimoo1aZv0OmAfcFszxFUpGBv+xZb0jT/J/YlDYkKkYYpriUy9JCYziJNX0E5GlLV5B vR7g== 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=+a3TTQwKZ1zs+Vcs/SHP+ZMoY6iHpHPUNUY7vuSWLjk=; b=JIXziYLFk2q7jkiOBNW/+Nzui7j5fFFhxG6WOlLaGH0nBIDAjhaJ1tnBmlI/1wh5mx /TLo8C+W/a0owVqn21xB7sd9DvOMR37FPjZsrlnR5pbh+6FlnXPMlDkcjDnai1Acv3/4 E1/zLOWGZhU47mv6e5K7+Sm2bwMogW/gEMP78m5Wn2D8hNPwqSlV40hZhx2NOZUTfXux YQOacAAZXqLmyJcZrp89Cu6EaCcj8N7qOykH0c6AeviRHYwddGoQ2UjTvIbAleFR6HRt UT0GGo8f4iOBiDMPH2upQMb6cJrKwXJWbnjK+nLVBObGzJGrhujlt4WPdmdxKSSBHX3m eHiQ== X-Gm-Message-State: ALQs6tBJvEXJsmaW5/+4kmHX8I7tB6IIHLlvBHONNP9BSVRnQVfmEYDB speIoWJjt7HOVUZbCnxGI2rXNypg2xvPxTtvLKA= X-Google-Smtp-Source: AIpwx497WZsENuRzh6gRqjo+FsmQli6MGcs9puepID7bNMqmoVOPSSrkKIXdsPRD6qxPYIRNwuFUO/ZsPEyRH4DD6MY= X-Received: by 10.107.186.70 with SMTP id k67mr2527015iof.166.1523400608867; Tue, 10 Apr 2018 15:50:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.242.173 with HTTP; Tue, 10 Apr 2018 15:50:08 -0700 (PDT) From: Dieter BSD Date: Tue, 10 Apr 2018 15:50:08 -0700 Message-ID: Subject: Realtek re(4) driver To: freebsd-net@freebsd.org, freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 22:50:10 -0000 Multiple people have found that FreeBSD's re(4) driver for Realtek Ethernet chips has problems. 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. :-( Rumor has it that Realtek has a driver that works properly with FreeBSD. FreeBSD's developers are apparently unable to: a) Fix the existing FreeBSD re(4) device driver so that it works correctly. b) Replace the existing FreeBSD re(4) device driver with Realtek's driver. c) Make Realtek's driver into a port/pkg. d) At least add a warning to the re(4) man page, with the URL for Realtek's driver. Therefore every user with Realtek Ethernet chips are forced to somehow discover that Realtek has a working driver, then somehow obtain a copy of this mythical driver, get it to compile and build a custom kernel. They then need to write a test suite and verify that Realtek's driver does in fact work properly for their applications. I am currently suffering data loss due to this. Therefore I am attempting to obtain a copy of the mythical Realtek device driver. I managed to find > http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=4&PNid=13&PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false But it does not work for me. It has a listing for > Description Version Update Time File Size Download Site 1 > FreeBSD 7.x and 8.0 1.94 2017/9/15 93k Global The machine with the re ports is running 10.3, hopefully the 7&8 code will compile and work on 10. But the real problem is that clicking on "Global" does not work. Some browsers do nothing. Firefox creates a new window with http://www.realtek.com.tw/downloads/ which is going backwards. I was expecting something like a tar file containing the source code. I also tried google, and emailing a FreeBSD user that runs the Realtek driver, but both pointed me to the above non-working URL. I'm told that seamonkey works, but... So my question is: could someone please tell me the URL that points *directly* to the mythical Realtek device driver? (without the broken javascheist garbage) From owner-freebsd-drivers@freebsd.org Tue Apr 10 22:55:00 2018 Return-Path: Delivered-To: freebsd-drivers@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 5AB20FA0C43; Tue, 10 Apr 2018 22:55:00 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::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 E51D8768C1; Tue, 10 Apr 2018 22:54:59 +0000 (UTC) (envelope-from dieterbsd@gmail.com) Received: by mail-io0-x242.google.com with SMTP id 141so267359iou.12; Tue, 10 Apr 2018 15:54:59 -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=g8umbL33JS4JMhFOtXihytGs1MPURHhV0U1dPQO1+1w=; b=PgtnKbfrJWtgc5gFg9ZM+xypbtqwBqoPnGuUmBRCMFI1YoLiYF22vdXhhBEfGYEw6E Hwncpu6scW5gYuCevrEsm/HFBKgWjjUiDIPRDWnZ4DdMgCTjwvOJa/BZcSN8nRP8cbGX qo/M55wB0HvWVzzaX1C4d85MG+S+YspToZfX1SOAtcMTGydmGgRWjpKq1keKkw5z4LwW yES4vgbLeP6DbUyIGSvuRaJEnwyUOJaTrHt1+0+7LSYWWs7B5xrlath/SamB6bfA1O0/ BQtUrNr0+2I68GET7sIXma9YmWbTkmDZrSGdpegyqXgAeWXV1lWUqS7BElOFGk/HR0kd ewNA== 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=g8umbL33JS4JMhFOtXihytGs1MPURHhV0U1dPQO1+1w=; b=gqPCLOtk+hXxuFh8F5zkw997KSP1fyiZ5je/liGyH9WAmOL4urtXXE5VAljrh5E6Pn 4Mte70+J9y4fK01S5hPEHx2ru6mTNYZrqypE+KKOUgC08A5Bz8qdwVeDdt5QJZve/L7a 08fgzMiSC9p4ku3C/CstatLO6JUgZMiU5e2td5Jo3bB3HUdGL6wtZilGWpSlvz523roQ W5Gg43b7oK4hv/S7PRO4c3VSTuhCZJtzvpxMZfoeLzWBI9ixV7L+aiymKQ6f5QBMag6l 09USs56vKvl9Ftvkr3tAQ3AySMjyMyv9P9TjsI7/LV8/t7NV80NTMnyTP81EFn8GiIKK Ydig== X-Gm-Message-State: ALQs6tCeAUptuoNk8MUG/8s22Fk/tzBFqc23Y/g+MSnTrme8rMhQSf1v YQHmu1UxtT6T3ZQ1hm0U8U3rV6K+vyLpUHp1XVg= X-Google-Smtp-Source: AIpwx49b56snKnBLOm9G8UeLhwQsi6yZfRa0YensdI0kYroj8e1y9NcH4URvtU0hynNigyLnQV5tjS7OAL/1wfZ091s= X-Received: by 10.107.146.136 with SMTP id u130mr2324773iod.96.1523400899098; Tue, 10 Apr 2018 15:54:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.242.173 with HTTP; Tue, 10 Apr 2018 15:54:58 -0700 (PDT) From: Dieter BSD Date: Tue, 10 Apr 2018 15:54:58 -0700 Message-ID: Subject: AX88179 USB-to-Ethernet is slow and silently corrupts data To: freebsd-usb@freebsd.org, freebsd-net@freebsd.org Cc: freebsd-drivers@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2018 22:55:00 -0000 10.3-RELEASE amd64 with ECC memory VIA VL805 USB 3.0 controller ue0 is Siig USB-to-Ethernet Chipset: AX88179 ugen0.7: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA) ue0: flags=8c43 metric 0 mtu 1500 options=8000b inet 10.0.210.66 netmask 0xffffff00 broadcast 10.0.210.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active If media is set to "1000baseT " it "works", but slowly, and received data is silently corrupted. :-( Transmitted data is not corrupted (tested with > 30 GB). ifconfig ue0 -txcsum "works", but still gives silent data corruption ifconfig ue0 -rxcsum (acts the same with or without txcsum) ping out netstat sees packets both directions, but ping doesn't see the response: 8 packets transmitted, 0 packets received, 100.0% packet loss ping in netstat sees packets in, but no responses going out I can see that some Ethernet controllers would not support checksum offloading, but it seems to me that turning the checksum offloading off should always work? (at the expense of more cpu load) Previously (2016 May): # ifconfig ue0 media 100baseTX-FDX fixed the input error problem and the data corruption problem, at the expense of making it even slower. Sent data from machine A with 10Mbps Ethernet. (Netgear Ethernet switch converts 10Mbps to 1000Mbps) Netstat did not report any input errors on ue0 and there was no data corruption. So ue0 can handle gigabit data rate, but gets input errors if packets arrive too frequently. I tried moving it to a USB-2 port. No data corruption, but USB-2 is slow. The chip performs a lot better for tweaktown: http://www.tweaktown.com/reviews/7243/vantec-cb-u300gna-usb-3-gigabit-network-adapter-review/index.html (Vantec CB-U300GNA with the same Asix AX88179 chip) "full duplex gigabit with 952 Mbps consistently across the chart" http://www.vantecusa.com/products_detail.php?p_id=143&p_name=USB+3.0+Gigabit+Ethernet+Adapter&pc_id=21&pc_name=Network&pt_id=5&pt_name=Accessories Asix AX88179 chip: http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112 "Supports Jumbo frame up to 4KB" But ifconfig rejects any value > 1500: ifconfig ue0 mtu 1501 ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument I tried mtu of 100, 500, 1000, 1400 but they all give rcp: lost connection USB disks are fast, so the USB controller seems to work ok. I also tried a Tek Republic TUN-300 which has the same AX88179, and it acts the same as the Siig. So, transmit works, but is slow. Receive works if the amount of traffic is low enough (limit rate of data sent, limit Ethernet speed, or use USB-2). But if data is received too fast it gets silently corrupted. Setting -rxcsum does not work, and cannot set mtu other than 1500. Questions: Why does -rxcsum not work? Why does attempting to set a larger mtu fail? Why does setting a smaller mtu make rcp fail? Why is the chip acting slow? How do I get it to work properly? (fast and without data corruption) From owner-freebsd-drivers@freebsd.org Wed Apr 11 06:30:54 2018 Return-Path: Delivered-To: freebsd-drivers@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 4E014F9B8A0 for ; Wed, 11 Apr 2018 06:30:54 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from lisa.milos.co.za (project.milos.za.net [109.169.49.139]) by mx1.freebsd.org (Postfix) with SMTP id 802737C7C9 for ; Wed, 11 Apr 2018 06:30:52 +0000 (UTC) (envelope-from clay@milos.co.za) Received: (qmail 65790 invoked by uid 89); 11 Apr 2018 06:24:10 -0000 Received: from unknown (HELO roundcube) (172.16.15.33) by vpopmail with SMTP; 11 Apr 2018 06:24:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 11 Apr 2018 08:24:10 +0200 From: clay@milos.co.za To: Dieter BSD Cc: freebsd-usb@freebsd.org, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org, owner-freebsd-usb@freebsd.org Subject: Re: AX88179 USB-to-Ethernet is slow and silently corrupts data In-Reply-To: References: Message-ID: <2cb00163a4b0165f6f05dff56a20ae56@milos.co.za> X-Sender: clay@milos.co.za User-Agent: Roundcube Webmail/1.3.3 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 06:30:54 -0000 I have one of these (I think it's the same chipset, I know it's AX88xxx) and I've used it before without issue. If I can find it at home and it's the same chipset I'll give it a whirl and check to confirm that it's not a hardware issue. Problem with these cheap USB-whatever adapters is that the quality control is not always server class :=) \\Clay On 2018-04-11 00:54, Dieter BSD wrote: > 10.3-RELEASE > amd64 with ECC memory > VIA VL805 USB 3.0 controller > ue0 is Siig USB-to-Ethernet Chipset: AX88179 > > ugen0.7: at usbus0, cfg=0 md=HOST > spd=SUPER (5.0Gbps) pwr=ON (124mA) > > ue0: flags=8c43 metric > 0 > mtu 1500 > options=8000b > inet 10.0.210.66 netmask 0xffffff00 broadcast 10.0.210.255 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > > If media is set to "1000baseT " it "works", but slowly, > and > received data is silently corrupted. :-( Transmitted data is not > corrupted (tested with > 30 GB). > > ifconfig ue0 -txcsum > "works", but still gives silent data corruption > > ifconfig ue0 -rxcsum (acts the same with or without txcsum) > ping out > netstat sees packets both directions, but ping doesn't see the > response: > 8 packets transmitted, 0 packets received, 100.0% packet loss > ping in > netstat sees packets in, but no responses going out > > I can see that some Ethernet controllers would not support checksum > offloading, > but it seems to me that turning the checksum offloading off should > always > work? (at the expense of more cpu load) > > Previously (2016 May): > # ifconfig ue0 media 100baseTX-FDX > fixed the input error problem and the data corruption problem, > at the expense of making it even slower. > > Sent data from machine A with 10Mbps Ethernet. (Netgear Ethernet > switch > converts 10Mbps to 1000Mbps) Netstat did not report any input errors > on > ue0 and there was no data corruption. So ue0 can handle gigabit data > rate, > but gets input errors if packets arrive too frequently. > > I tried moving it to a USB-2 port. No data corruption, but USB-2 is > slow. > > The chip performs a lot better for tweaktown: > > http://www.tweaktown.com/reviews/7243/vantec-cb-u300gna-usb-3-gigabit-network-adapter-review/index.html > (Vantec CB-U300GNA with the same Asix AX88179 chip) > "full duplex gigabit with 952 Mbps consistently across the chart" > > http://www.vantecusa.com/products_detail.php?p_id=143&p_name=USB+3.0+Gigabit+Ethernet+Adapter&pc_id=21&pc_name=Network&pt_id=5&pt_name=Accessories > > Asix AX88179 chip: > http://www.asix.com.tw/products.php?op=pItemdetail&PItemID=131;71;112 > "Supports Jumbo frame up to 4KB" > > But ifconfig rejects any value > 1500: > ifconfig ue0 mtu 1501 > ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument > > I tried mtu of 100, 500, 1000, 1400 but they all give > rcp: lost connection > > USB disks are fast, so the USB controller seems to work ok. > > I also tried a Tek Republic TUN-300 which has the same AX88179, > and it acts the same as the Siig. > > So, transmit works, but is slow. Receive works if the amount of > traffic > is low enough (limit rate of data sent, limit Ethernet speed, or > use USB-2). But if data is received too fast it gets silently > corrupted. > Setting -rxcsum does not work, and cannot set mtu other than 1500. > > Questions: > Why does -rxcsum not work? > Why does attempting to set a larger mtu fail? > Why does setting a smaller mtu make rcp fail? > Why is the chip acting slow? > How do I get it to work properly? (fast and without data corruption) > _______________________________________________ > freebsd-usb@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" From owner-freebsd-drivers@freebsd.org Wed Apr 11 07:10:46 2018 Return-Path: Delivered-To: freebsd-drivers@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 C3D9CF9E739; Wed, 11 Apr 2018 07:10:46 +0000 (UTC) (envelope-from vterziev@gvcgroup.com) Received: from mgate03.itsfogo.com (mgate03.itsfogo.com [195.72.134.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.itsfogo.com", Issuer "thawte SSL CA - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4656D8750F; Wed, 11 Apr 2018 07:10:45 +0000 (UTC) (envelope-from vterziev@gvcgroup.com) From: Vladimir Terziev To: Dieter BSD CC: "freebsd-net@freebsd.org" , "freebsd-drivers@freebsd.org" , "freebsd-hackers@freebsd.org" Subject: Re: Realtek re(4) driver Thread-Topic: Realtek re(4) driver Thread-Index: AQHT0R8OI42h+gu5D0y7MqkwOTG+kqP7AGUA Date: Wed, 11 Apr 2018 06:55:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) x-originating-ip: [10.138.239.10] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 07:10:47 -0000 SGkgRGlldGVyLA0KDQppIGhhdmUgbWFuYWdlZCB0byBkb3dubG9hZCB0aGUgZHJpdmVyIGZyb20g dGhlIGxpbmsgdGhhdCB5b3UgcHJvdmlkZWQgYnkganVzdCBjbGlja2luZyB0aGUg4oCcR2xvYmFs 4oCdIGxpbmsuDQoNCkp1c3QgbGV0IG1lIGtub3cgaWYgeW91IHdhbnQgbWUgdG8gc2VuZCBpdCB0 byB5b3UuDQoNCg0KUmVnYXJkcywNCg0KVmxhZGltaXINCg0KDQo+IE9uIDExIEFwciAyMDE4LCBh dCAwMTo1MCwgRGlldGVyIEJTRCA8ZGlldGVyYnNkQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBN dWx0aXBsZSBwZW9wbGUgaGF2ZSBmb3VuZCB0aGF0IEZyZWVCU0QncyByZSg0KSBkcml2ZXIgZm9y IFJlYWx0ZWsNCj4gRXRoZXJuZXQgY2hpcHMgaGFzIHByb2JsZW1zLiAgU29tZXRoaW5nIGxpa2Ug YSByY3AoMSkgd2l0aCBhbm90aGVyDQo+IEZyZWVCU0QgYm94IG1lcmVseSBydW5zIHNsb3dlciBk dWUgdG8gdGhlIHN0YWxscywgYnV0IGlmIHRoZSBvdGhlciBlbmQNCj4gaGFzIGJ1Z2d5IG5ldHdv cmsgY29kZSBhbmQvb3IgaWYgdGhlIHRyYW5zZmVyIGlzIGZvcmNlZCB0byB1c2UgVURQDQo+IChV bnJlbGlhYmxlIERhdGEgUHJvdG9jb2wpIGRhdGEgaXMgbG9zdC4gIDotKA0KPiANCj4gUnVtb3Ig aGFzIGl0IHRoYXQgUmVhbHRlayBoYXMgYSBkcml2ZXIgdGhhdCB3b3JrcyBwcm9wZXJseSB3aXRo IEZyZWVCU0QuDQo+IA0KPiBGcmVlQlNEJ3MgZGV2ZWxvcGVycyBhcmUgYXBwYXJlbnRseSB1bmFi bGUgdG86DQo+IGEpIEZpeCB0aGUgZXhpc3RpbmcgRnJlZUJTRCByZSg0KSBkZXZpY2UgZHJpdmVy IHNvIHRoYXQgaXQgd29ya3MgY29ycmVjdGx5Lg0KPiBiKSBSZXBsYWNlIHRoZSBleGlzdGluZyBG cmVlQlNEIHJlKDQpIGRldmljZSBkcml2ZXIgd2l0aCBSZWFsdGVrJ3MgZHJpdmVyLg0KPiBjKSBN YWtlIFJlYWx0ZWsncyBkcml2ZXIgaW50byBhIHBvcnQvcGtnLg0KPiBkKSBBdCBsZWFzdCBhZGQg YSB3YXJuaW5nIHRvIHRoZSByZSg0KSBtYW4gcGFnZSwgd2l0aCB0aGUgVVJMIGZvcg0KPiAgIFJl YWx0ZWsncyBkcml2ZXIuDQo+IA0KPiBUaGVyZWZvcmUgZXZlcnkgdXNlciB3aXRoIFJlYWx0ZWsg RXRoZXJuZXQgY2hpcHMgYXJlIGZvcmNlZCB0byBzb21laG93DQo+IGRpc2NvdmVyIHRoYXQgUmVh bHRlayBoYXMgYSB3b3JraW5nIGRyaXZlciwgdGhlbiBzb21laG93IG9idGFpbiBhIGNvcHkNCj4g b2YgdGhpcyBteXRoaWNhbCBkcml2ZXIsIGdldCBpdCB0byBjb21waWxlIGFuZCBidWlsZCBhIGN1 c3RvbSBrZXJuZWwuDQo+IFRoZXkgdGhlbiBuZWVkIHRvIHdyaXRlIGEgdGVzdCBzdWl0ZSBhbmQg dmVyaWZ5IHRoYXQgUmVhbHRlaydzIGRyaXZlcg0KPiBkb2VzIGluIGZhY3Qgd29yayBwcm9wZXJs eSBmb3IgdGhlaXIgYXBwbGljYXRpb25zLg0KPiANCj4gSSBhbSBjdXJyZW50bHkgc3VmZmVyaW5n IGRhdGEgbG9zcyBkdWUgdG8gdGhpcy4gIFRoZXJlZm9yZSBJIGFtDQo+IGF0dGVtcHRpbmcgdG8g b2J0YWluIGEgY29weSBvZiB0aGUgbXl0aGljYWwgUmVhbHRlayBkZXZpY2UgZHJpdmVyLg0KPiBJ IG1hbmFnZWQgdG8gZmluZA0KPiANCj4+IGh0dHA6Ly93d3cucmVhbHRlay5jb20udHcvRG93bmxv YWRzL2Rvd25sb2Fkc1ZpZXcuYXNweD9MYW5naWQ9NCZQTmlkPTEzJlBGaWQ9NSZMZXZlbD01JkNv bm49NCZEb3duVHlwZUlEPTMmR2V0RG93bj1mYWxzZQ0KPiANCj4gQnV0IGl0IGRvZXMgbm90IHdv cmsgZm9yIG1lLiAgSXQgaGFzIGEgbGlzdGluZyBmb3INCj4gDQo+PiBEZXNjcmlwdGlvbiAgICAg ICAgIFZlcnNpb24gVXBkYXRlIFRpbWUgRmlsZSBTaXplIERvd25sb2FkIFNpdGUgMQ0KPj4gRnJl ZUJTRCA3LnggYW5kIDguMCAxLjk0ICAgIDIwMTcvOS8xNSAgIDkzayAgICAgICBHbG9iYWwNCj4g DQo+IFRoZSBtYWNoaW5lIHdpdGggdGhlIHJlIHBvcnRzIGlzIHJ1bm5pbmcgMTAuMywgaG9wZWZ1 bGx5IHRoZSA3JjggY29kZQ0KPiB3aWxsIGNvbXBpbGUgYW5kIHdvcmsgb24gMTAuICBCdXQgdGhl IHJlYWwgcHJvYmxlbSBpcyB0aGF0IGNsaWNraW5nIG9uDQo+ICJHbG9iYWwiIGRvZXMgbm90IHdv cmsuICBTb21lIGJyb3dzZXJzIGRvIG5vdGhpbmcuICBGaXJlZm94IGNyZWF0ZXMNCj4gYSBuZXcg d2luZG93IHdpdGggaHR0cDovL3d3dy5yZWFsdGVrLmNvbS50dy9kb3dubG9hZHMvDQo+IHdoaWNo IGlzIGdvaW5nIGJhY2t3YXJkcy4gIEkgd2FzIGV4cGVjdGluZyBzb21ldGhpbmcgbGlrZSBhIHRh ciBmaWxlDQo+IGNvbnRhaW5pbmcgdGhlIHNvdXJjZSBjb2RlLg0KPiANCj4gSSBhbHNvIHRyaWVk IGdvb2dsZSwgYW5kIGVtYWlsaW5nIGEgRnJlZUJTRCB1c2VyIHRoYXQgcnVucyB0aGUgUmVhbHRl aw0KPiBkcml2ZXIsIGJ1dCBib3RoIHBvaW50ZWQgbWUgdG8gdGhlIGFib3ZlIG5vbi13b3JraW5n IFVSTC4gIEknbQ0KPiB0b2xkIHRoYXQgc2VhbW9ua2V5IHdvcmtzLCBidXQuLi4NCj4gDQo+IFNv IG15IHF1ZXN0aW9uIGlzOiBjb3VsZCBzb21lb25lIHBsZWFzZSB0ZWxsIG1lIHRoZSBVUkwgdGhh dCBwb2ludHMNCj4gKmRpcmVjdGx5KiB0byB0aGUgbXl0aGljYWwgUmVhbHRlayBkZXZpY2UgZHJp dmVyPyAgKHdpdGhvdXQNCj4gdGhlIGJyb2tlbiBqYXZhc2NoZWlzdCBnYXJiYWdlKQ0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmcmVlYnNkLW5l dEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4gaHR0cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtbmV0DQo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBt YWlsIHRvICJmcmVlYnNkLW5ldC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCg0K