From owner-freebsd-arch@freebsd.org Tue Aug 25 06:44:39 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 607A799AD75 for ; Tue, 25 Aug 2015 06:44:39 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 2FE59DC6 for ; Tue, 25 Aug 2015 06:44:39 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by igfj19 with SMTP id j19so4600484igf.0 for ; Mon, 24 Aug 2015 23:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=3YB3EH5gMc6irmSc1tdwU3AV1YtJ8E0t0nhnYFNPTTE=; b=cgRrKkloy8WEXqrPVBLOFUgXKTdvFXVF3Ul5ZNM47660bLinEFLHRp91/c2+uBSDbC FGfZQK6W0uEJX/BRt9d4H1UsjMpM+4NI2pgeyNi98hiHEAEOnuKkAZQl2O60QCN2tU2n JllvANPCY70Z7iEq5GumL39LftOtiR0WCmEZv6wX2yrjEFFXoNtTp0GPQlPUq2p+TaKg 0BrOnNngoz1IeJjZv/ugHKGu8Pod3ZXUu8Ye5STnFDKh5WAUwX5bXiQcZb4tJMxXylLP Ty9zEhX4u93QQbV1gfG/ku6w5dMxf/tYHvllzr6FEcxZWrpel5dBemAR3TAwW+zVWgDk avvg== MIME-Version: 1.0 X-Received: by 10.50.43.131 with SMTP id w3mr900706igl.8.1440485078636; Mon, 24 Aug 2015 23:44:38 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.36.58.149 with HTTP; Mon, 24 Aug 2015 23:44:38 -0700 (PDT) Date: Mon, 24 Aug 2015 23:44:38 -0700 X-Google-Sender-Auth: YR77VzPr3nBJsVRzSoPYfe8OPjc Message-ID: Subject: Devices with 36-bit paddr on 32-bit system From: Justin Hibbits To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 06:44:39 -0000 With my work porting FreeBSD to PowerPC e500mc and e5500, I have devices in my device tree mapped well above the 4GB mark (0xffexxxxxx), and have no idea how to properly address them for resources in rman. Do we already have a solution to support this? Part of the problem is the powerpc nexus does a straight convert to vm_offset_t of rman_get_start() (itself returning a u_long), and vm_offset_t is not necessarily equal to vm_paddr_t (on Book-E powerpc vm_offset_t is 32-bits, vm_paddr_t is 64-bits). Could rman be thought that resources aren't necessarily u_long? The only thought I have is to assume in the nexus code that the bottom 4 bits of the 32-bit address are actually the top bits of the 36-bit address, and generate those in ofw_bus_reg_to_rl(), since the bottom 12 bits can be ignored anyways (pmap_mapdev() only maps full pages at a minimum). This seems kinda kludgy to me, though. Any thoughts? - Justin From owner-freebsd-arch@freebsd.org Tue Aug 25 15:56:00 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D30999AF50 for ; Tue, 25 Aug 2015 15:56:00 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (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 C2DBF1F76 for ; Tue, 25 Aug 2015 15:55:59 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from [10.1.254.15] (cerberus.brkt.com [208.185.168.138]) (authenticated bits=0) by mail.xcllnt.net (8.15.2/8.15.2) with ESMTPSA id t7PFtpWC070237 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Aug 2015 08:55:53 -0700 (PDT) (envelope-from marcel@xcllnt.net) Subject: Re: Devices with 36-bit paddr on 32-bit system Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_93356986-19A1-41F2-9B7E-7CCD32DD0083"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Marcel Moolenaar In-Reply-To: Date: Tue, 25 Aug 2015 08:55:45 -0700 Cc: "freebsd-arch@freebsd.org" Message-Id: References: To: Justin Hibbits X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 15:56:00 -0000 --Apple-Mail=_93356986-19A1-41F2-9B7E-7CCD32DD0083 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 24, 2015, at 11:44 PM, Justin Hibbits = wrote: >=20 > With my work porting FreeBSD to PowerPC e500mc and e5500, I have > devices in my device tree mapped well above the 4GB mark > (0xffexxxxxx), and have no idea how to properly address them for > resources in rman. Do we already have a solution to support this? > Part of the problem is the powerpc nexus does a straight convert to > vm_offset_t of rman_get_start() (itself returning a u_long), and > vm_offset_t is not necessarily equal to vm_paddr_t (on Book-E powerpc > vm_offset_t is 32-bits, vm_paddr_t is 64-bits). I think the best solution is to represent a resource address space with a type other than u_long. It makes sense to have it use bus_addr_t or vm_paddr_t for example. Such a change comes at a high price for sure, but you=E2=80=99ll fix it once and for all. I don=E2=80=99t think you should kluge your way out of this... -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_93356986-19A1-41F2-9B7E-7CCD32DD0083 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIbBAEBCgAGBQJV3JACAAoJEIda8t8f0tjjiv8P9Ag0czqwx88SEHdmFnBv+euC IJngr0Nt6JmteOXI4PxI+WjjH7VfUusN2rxh8yU8S2bKlYamjw+9WhyGnXIhf6XA rjZV+Sevq5k/CTb2hVguEDl1T7PseY4HBvnALsCYcDm76AFABt23NVISp6AD85uH 2llIdVTC1Gy4hlmlbAb7lTF9YNK46ky0+Tk+xyN2y1IOaSdrf4WI5IE0ph5AlAqn N9f17+Lmu/BEsCy6TDulFpMU1aY/d2G1vu3EBHZ7r62icKPC7epbdiBJkfwZt5w4 7wN7gzqpGBlkvOPvJ2tRIiIU1pXKvAxEX9rojt6PfpEdRibX3UejNG+rwkTjw6HV lqZ6ko3ZeqWL4vWCw4L612aK/stFZ4dYtiX0PAlPrw/i6Tqnu9HG6mxov9SvMT0F QMpYi64rHa1FYf13nLeogtUDzlOENO9ox5zkAx2csg4bFGiw2hHmAOhuNS7HjYdv PW2EYYchn6WliKStO0U98VX3emm4hKc28mpxUQ4JPq2j6ATVaNOsJWYcWUvHjk7/ y9gqxWGfYdTobHYOJ7jAA8SnTurXLlQiSQluUcIbl6UHFpqW2jWOgJUj4sAT5mEt zcqaHF6HAgB0tPWjqFRMRAsCIfssT0BNpd4KW+43tvSkPprkTHDrbcj7na3BxpO9 FeoAlcT/qdvEsqtYJxA= =BAkx -----END PGP SIGNATURE----- --Apple-Mail=_93356986-19A1-41F2-9B7E-7CCD32DD0083-- From owner-freebsd-arch@freebsd.org Wed Aug 26 01:14:47 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66D4A9C265F for ; Wed, 26 Aug 2015 01:14:47 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 489F4B3F for ; Wed, 26 Aug 2015 01:14:47 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t7Q1EZZw022151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Aug 2015 18:14:35 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t7Q1EY2U022150; Tue, 25 Aug 2015 18:14:34 -0700 (PDT) (envelope-from jmg) Date: Tue, 25 Aug 2015 18:14:34 -0700 From: John-Mark Gurney To: Justin Hibbits Cc: "freebsd-arch@freebsd.org" Subject: Re: Devices with 36-bit paddr on 32-bit system Message-ID: <20150826011434.GO33167@funkthat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Tue, 25 Aug 2015 18:14:35 -0700 (PDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 01:14:47 -0000 Justin Hibbits wrote this message on Mon, Aug 24, 2015 at 23:44 -0700: > With my work porting FreeBSD to PowerPC e500mc and e5500, I have > devices in my device tree mapped well above the 4GB mark > (0xffexxxxxx), and have no idea how to properly address them for > resources in rman. Do we already have a solution to support this? > Part of the problem is the powerpc nexus does a straight convert to > vm_offset_t of rman_get_start() (itself returning a u_long), and > vm_offset_t is not necessarily equal to vm_paddr_t (on Book-E powerpc > vm_offset_t is 32-bits, vm_paddr_t is 64-bits). > > Could rman be thought that resources aren't necessarily u_long? The > only thought I have is to assume in the nexus code that the bottom 4 > bits of the 32-bit address are actually the top bits of the 36-bit > address, and generate those in ofw_bus_reg_to_rl(), since the bottom > 12 bits can be ignored anyways (pmap_mapdev() only maps full pages at > a minimum). This seems kinda kludgy to me, though. > > Any thoughts? I'd look at how i386's PAE does it, as this is exactly the same type of issue that PAE has... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Wed Aug 26 01:17:44 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EDF99C274A for ; Wed, 26 Aug 2015 01:17:44 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from iredmail.onthenet.com.au (iredmail.onthenet.com.au [203.13.68.150]) (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 31908C28 for ; Wed, 26 Aug 2015 01:17:43 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from localhost (iredmail.onthenet.com.au [127.0.0.1]) by iredmail.onthenet.com.au (Postfix) with ESMTP id 61F662811A0 for ; Wed, 26 Aug 2015 11:17:41 +1000 (AEST) X-Amavis-Modified: Mail body modified (using disclaimer) - iredmail.onthenet.com.au Received: from iredmail.onthenet.com.au ([127.0.0.1]) by localhost (iredmail.onthenet.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvJCTlb2tpZO for ; Wed, 26 Aug 2015 11:17:41 +1000 (AEST) Received: from Peters-MacBook-Pro.local (unknown [64.245.0.210]) by iredmail.onthenet.com.au (Postfix) with ESMTPSA id E30F6280F8B; Wed, 26 Aug 2015 11:17:31 +1000 (AEST) Subject: Re: Devices with 36-bit paddr on 32-bit system To: John-Mark Gurney , Justin Hibbits References: <20150826011434.GO33167@funkthat.com> Cc: "freebsd-arch@freebsd.org" From: Peter Grehan Message-ID: <55DD13A9.9070005@freebsd.org> Date: Tue, 25 Aug 2015 18:17:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150826011434.GO33167@funkthat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 01:17:44 -0000 > I'd look at how i386's PAE does it, as this is exactly the same type > of issue that PAE has... i386 PAE doesn't have any h/w resources at addresses > 4GB, which is the problem Justin is seeing on his ppc platform. later, Peter. From owner-freebsd-arch@freebsd.org Wed Aug 26 16:30:51 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB31C9C32AF for ; Wed, 26 Aug 2015 16:30:51 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (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 D224C809 for ; Wed, 26 Aug 2015 16:30:51 +0000 (UTC) (envelope-from sbruno@freebsd.org) Received: from [192.168.200.200] (unknown [50.136.155.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 490AB193655 for ; Wed, 26 Aug 2015 16:30:49 +0000 (UTC) To: freebsd-arch@freebsd.org From: Sean Bruno Subject: Network card interrupt handling X-Enigmail-Draft-Status: N1210 Message-ID: <55DDE9B8.4080903@freebsd.org> Date: Wed, 26 Aug 2015 09:30:48 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 16:30:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 We've been diagnosing what appeared to be out of order processing in the network stack this week only to find out that the network card driver was shoveling bits to us out of order (em). This *seems* to be due to a design choice where the driver is allowed to assert a "soft interrupt" to the h/w device while real interrupts are disabled. This allows a fake "em_msix_rx" to be started *while* "em_handle_que" is running from the taskqueue. We've isolated and worked around this by setting our processing_limit in the driver to - -1. This means that *most* packet processing is now handled in the MSI-X handler instead of being deferred. Some periodic interference is still detectable via em_local_timer() which causes one of these "fake" interrupt assertions in the normal, card is *not* hung case. Both functions use identical code for a start. Both end up down inside of em_rxeof() to process packets. Both drop the RX lock prior to handing the data up the network stack. This means that the em_handle_que running from the taskqueue will be preempted. Dtrace confirms that this allows out of order processing to occur at times and generates a lot of resets. The reason I'm bringing this up on -arch and not on -net is that this is a common design pattern in some of the Ethernet drivers. We've done preliminary tests on a patch that moves *all* processing of RX packets to the rx_task taskqueue, which means that em_handle_que is now the only path to get packets processed. https://people.freebsd.org/~sbruno/em_interupt_to_taskqueue.diff My sense is that this is a slightly "better" method to handle the packets but removes some immediacy from packet processing since all processing is deferred. However, all packet processing is now serialized per queue, which I think is the proper implementation. Am I smoking "le dope" here or is this the way forward? sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJV3em1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5klyYH+wX22JSRYkKMeCJGVSi1dJiM fcd+DWZVhru2qyUNEfhBSoGEgi7HzXqaBwddy7GK2IRtbKeRlF/oebsII941SIsz t2f35MoZunw0rWObIEw4WxxkXAajeATDjx87wozVmsZZ40JbmgZ0jKIGXiNie3Is 04pkXiIOElWqjlLtFlkITUUrOeKsN7kKbwaZAHYeFRdbUgsnxsh7fRvsFucOCgyr CONHBGWEwu/g50YUruR+rPOHFAA1HD3dQuIoHcTjQx/uX4l5bw+8CFzzMjpw6X9d G+boH6l1ZZ6U3uZCXOSmkPiXka7Ix8rdbUyrUrJTJrGEB7+U7rF2lSSq8cX+4pk= =UibL -----END PGP SIGNATURE----- From owner-freebsd-arch@freebsd.org Wed Aug 26 16:36:09 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 164809C3576 for ; Wed, 26 Aug 2015 16:36:09 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (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 9945410C5; Wed, 26 Aug 2015 16:36:08 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by laba3 with SMTP id a3so123359985lab.1; Wed, 26 Aug 2015 09:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DbRAPayfsW6+JWlPkgVNl6ni7oZPoWyeQwM97m6DRDo=; b=WiNK64WRwPhG5KFKRATDYkksCeGW3yCvyhym79U+cdHDWScDGSt6laXadvtvBSFOec /fpEgKx0M+GrlIflaFBVunm1pJqi8f1zBdD4fY+gXL+C4TRk58r+aW3D82DvNmcDReJk gH9Mc/FrX0ixQm3gY8SWzNVKNcUkByYlFMaLN8ZLN4dLU5YXmNpygnCNds0MKu3OtiEv VfHbzN4bfjGLzzGBk8c/W0Hh1VYmJoQrdA9Uj7LGcxuuzNVcqPVdndA5j8kZxjE3+bIj PeH04WxEjm9WRNOB0Jr8lReUfS0UIFwT1EBW1PPB7QIX088wVWWc8VoyRK7U8H7f8Qyc eNeA== MIME-Version: 1.0 X-Received: by 10.152.29.6 with SMTP id f6mr30754084lah.85.1440606966581; Wed, 26 Aug 2015 09:36:06 -0700 (PDT) Received: by 10.112.19.1 with HTTP; Wed, 26 Aug 2015 09:36:06 -0700 (PDT) In-Reply-To: <55DDE9B8.4080903@freebsd.org> References: <55DDE9B8.4080903@freebsd.org> Date: Wed, 26 Aug 2015 09:36:06 -0700 Message-ID: Subject: Re: Network card interrupt handling From: Jack Vogel To: Sean Bruno Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 16:36:09 -0000 I recall actually trying something like this once myself Sean, but if memory serves the performance was poor enough that I decided against pursuing it. Still, maybe it deserves further investigation. Jack On Wed, Aug 26, 2015 at 9:30 AM, Sean Bruno wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > We've been diagnosing what appeared to be out of order processing in > the network stack this week only to find out that the network card > driver was shoveling bits to us out of order (em). > > This *seems* to be due to a design choice where the driver is allowed > to assert a "soft interrupt" to the h/w device while real interrupts > are disabled. This allows a fake "em_msix_rx" to be started *while* > "em_handle_que" is running from the taskqueue. We've isolated and > worked around this by setting our processing_limit in the driver to > - -1. This means that *most* packet processing is now handled in the > MSI-X handler instead of being deferred. Some periodic interference > is still detectable via em_local_timer() which causes one of these > "fake" interrupt assertions in the normal, card is *not* hung case. > > Both functions use identical code for a start. Both end up down > inside of em_rxeof() to process packets. Both drop the RX lock prior > to handing the data up the network stack. > > This means that the em_handle_que running from the taskqueue will be > preempted. Dtrace confirms that this allows out of order processing > to occur at times and generates a lot of resets. > > The reason I'm bringing this up on -arch and not on -net is that this > is a common design pattern in some of the Ethernet drivers. We've > done preliminary tests on a patch that moves *all* processing of RX > packets to the rx_task taskqueue, which means that em_handle_que is > now the only path to get packets processed. > > > https://people.freebsd.org/~sbruno/em_interupt_to_taskqueue.diff > > My sense is that this is a slightly "better" method to handle the > packets but removes some immediacy from packet processing since all > processing is deferred. However, all packet processing is now > serialized per queue, which I think is the proper implementation. > > Am I smoking "le dope" here or is this the way forward? > > sean > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQF8BAEBCgBmBQJV3em1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx > MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5klyYH+wX22JSRYkKMeCJGVSi1dJiM > fcd+DWZVhru2qyUNEfhBSoGEgi7HzXqaBwddy7GK2IRtbKeRlF/oebsII941SIsz > t2f35MoZunw0rWObIEw4WxxkXAajeATDjx87wozVmsZZ40JbmgZ0jKIGXiNie3Is > 04pkXiIOElWqjlLtFlkITUUrOeKsN7kKbwaZAHYeFRdbUgsnxsh7fRvsFucOCgyr > CONHBGWEwu/g50YUruR+rPOHFAA1HD3dQuIoHcTjQx/uX4l5bw+8CFzzMjpw6X9d > G+boH6l1ZZ6U3uZCXOSmkPiXka7Ix8rdbUyrUrJTJrGEB7+U7rF2lSSq8cX+4pk= > =UibL > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Wed Aug 26 17:20:11 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DD809C34F5 for ; Wed, 26 Aug 2015 17:20:11 +0000 (UTC) (envelope-from imp@bsdimp.com) 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 19B3EFC4 for ; Wed, 26 Aug 2015 17:20:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1716D9C34F4; Wed, 26 Aug 2015 17:20:11 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0D219C34F3 for ; Wed, 26 Aug 2015 17:20:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (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 C9805FC3 for ; Wed, 26 Aug 2015 17:20:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by pabzx8 with SMTP id zx8so76202108pab.1 for ; Wed, 26 Aug 2015 10:20:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type:subject:date:message-id :to:mime-version; bh=WwBdS4EPEGJeI/gxigw1UHgqWlnOJ6kQL46B3Q1Ymrg=; b=LOjJk4OT+TLB0zou1VuxAYFXKzt/60tojgNPAlArYbRfYyXr6eWl61TeWPWszQ3KHr duGA+Azxd8Sa3JOaouFTYmTfmw7dmq//FeAj9vgTj7W/qkYDI1V2yfwp906keN7cspRH nCh6y4Z7ajHzGfZy+AWtTi+QwkeMksffKGyZgimE58A1QuxdySWoOyuX1k1rGI/Qp+Kr BRzwSE24e39NKJAApzjjYZJLcmGIzNjuvUik0rSIzJGUvWsuRkqh1SJShsn0Z43vfawn Wg9YFyeLM91bydZVbsxiXP3lcpTYiEqJLwp5wySW57QwfO2NxWflSvy9Iip68wjWTl9Z glyQ== X-Gm-Message-State: ALoCoQn/xepedwWkyHCj2dnCwqjzBaNKlyi8K+W6gW3sIbzEjvi689kD10yQUvBjiuveDMF5zNzG X-Received: by 10.66.221.193 with SMTP id qg1mr62390596pac.103.1440609609342; Wed, 26 Aug 2015 10:20:09 -0700 (PDT) Received: from [100.127.144.155] ([69.53.245.35]) by smtp.gmail.com with ESMTPSA id b6sm25366058pdo.63.2015.08.26.10.20.08 for (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Aug 2015 10:20:08 -0700 (PDT) Sender: Warner Losh From: Warner Losh X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_E012EBF8-BAA7-4B92-BCE8-E4C098D47E92"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: exporting INVARIANTS easily Date: Wed, 26 Aug 2015 11:20:06 -0600 Message-Id: To: "freebsd-arch@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 17:20:11 -0000 --Apple-Mail=_E012EBF8-BAA7-4B92-BCE8-E4C098D47E92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, Many of the performance eating features are exported via some kind of = sysctl, usually patterned after the case of witness as debug.foo. INVARIANTS isn=E2=80=99t= one of those features. https://reviews.freebsd.org/D3488 implements debug.invariants. Please comment. I=E2=80=99d thought about adding it to the kern.features sysctl, but = thought better of it since it isn=E2=80=99t a facility that people can use. If you include the kernel config in the kernel, you can get this = information via config -x | grep INVARIANTS but not all kernels do that. This is more robust. I also know that you can load some modules compiled INVARIANTS when the = base kernel isn=E2=80=99t built that way and this won=E2=80=99t reflect that. = There=E2=80=99s no good want to include that information and is an uncommon use case. Our use case? We have a raft of test machines. Most run without = INVARIANTS since we want to characterize the performance of the release under test. Some = are running INVARIANTS since we want to test the robustness as well, even at the = expense of some performance. To ensure we don=E2=80=99t accidentally include = INVARIANTS systems in the performance number, we=E2=80=99ve adding a key to an internal = database that=E2=80=99s driven off this sysctl. Comments? Warner --Apple-Mail=_E012EBF8-BAA7-4B92-BCE8-E4C098D47E92 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV3fVGAAoJEGwc0Sh9sBEAfNIQALys9LOQgbaztLjuACdJe7NH gpVlHIbcrwAk6+hFmIEVOvRHbwryCoTpII4I2dQexD8Or3NEzXzCXhmzTXY91NQ8 ud/rR74JekcALMPP4MkX+qCY/OeoSsE6MOFepcrctRAeujZvDa6y7FLeyhl7acHr xBLSsr+mPk2IFgYImTaiEvcz3zZxVp2jentW8LoPSQGlnRguypqLgoSnZiRb5sow dIuk+Qt6iQhvqIXXzceJJj3bfDaMp52aeGKn02fq5oZDLRCD/SHs4wjUymMb5tP6 uUnF6zQz8bKcGmLf/3OqIzCm58lbMiif4rGN9BpgXpyMv7vd62tb3yIVruY3nV83 MTVMW2TfAqyyY9liZhFdQtHsoxKv/qXX8xXZjv56OU/VSvM53sT09Q+cVeVcY8d0 a00++wgwHyzl5Bqe5H+TPsOpNgUeE8Jfq24KxToqU21YCw+S/iPt6nVa3mCye4GQ 9PJaruTaSAvvFoE8PivAWTJ7Ro53bzIrKFyJDFjANIOr+zk61fd/YOuJ/LZZGD4E Je8MUKJEYKPk7YfQKrjcgEdC2+CQpUzlXSHaok7DXRdIwt8l7ozlUqL6/qobtj0W rAOJl4C4wBcZCITZGjL5qtFvBsPMdXCluhajsNtis4vZwQf3fyI022g6DY3osvCw XoV1XnTbuJNT3Rf7UBQM =D55O -----END PGP SIGNATURE----- --Apple-Mail=_E012EBF8-BAA7-4B92-BCE8-E4C098D47E92-- From owner-freebsd-arch@freebsd.org Fri Aug 28 18:27:12 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D96509C5648 for ; Fri, 28 Aug 2015 18:27:12 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AD4641125; Fri, 28 Aug 2015 18:27:12 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t7SIR5mq075778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2015 11:27:05 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t7SIR5WR075777; Fri, 28 Aug 2015 11:27:05 -0700 (PDT) (envelope-from jmg) Date: Fri, 28 Aug 2015 11:27:05 -0700 From: John-Mark Gurney To: John Baldwin Cc: "'freebsd-arch'" Subject: Re: Supporting cross-debugging vmcores in libkvm Message-ID: <20150828182705.GD33167@funkthat.com> References: <3121152.ujdxFEovO3@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3121152.ujdxFEovO3@ralph.baldwin.cx> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Fri, 28 Aug 2015 11:27:05 -0700 (PDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:27:13 -0000 John Baldwin wrote this message on Tue, Aug 04, 2015 at 10:56 -0700: > Many debuggers (recent gdb and lldb) support cross-architecture debugging > just fine. My current WIP port of kgdb to gdb7 supports cross-debugging for > remote targets already, but I wanted it to also support cross-debugging for > vmcores. > > The existing libkvm/kgdb code in the tree has some limited support for > cross-debugging. It requires building a custom libkvm (e.g. libkvm-i386.a) > and custom kgdb for each target platform. However, gdb (and lldb) both > support multiple targets in a single binary, so I'd like to have a single > kgdb binary that can cross-debug anything. > > I started hacking on libkvm last weekend and have a prototype that I've used > (along with some patches to my kgdb port) to debug an amd64 vmcore on an > i386 machine and vice versa. > > To do this I've made some additions to the libkvm API: > > 1) A new 'kvaddr_t' type represents a kernel virtual address. This is > similar to the psaddr_t type used for MI process addresses in userland > debugging. I almost reused psaddr_t directly, but that would have made > depend on . Instead, I opted for a separate > type. It is currently a uint64_t. I like this.. W/ the work Lovasko has been working on, having this type is good and makes the most sense... > 2) A new 'struct kvm_nlist'. This is a stripped-down version of > 'struct nlist' that uses kvadd_t for n_value instead of an unsigned > long. > > 3) kvm_native() returns true if an open kvm descriptor is for a native > kernel and memory image. > > 4) kvm_nlist2() is like kvm_nlist() but it uses 'struct kvm_nlist' > instead of 'struct nlist'. Internally symbol names are always > resolved to kvaddr_t addresses rather than u_long addresses. > Native kernels still use _fdnlist() from libc to resolve symbols. > Cross kernels use a caller supplied function to resolve symbols > (the older cross code for libkvm required the caller to provide > a global ps_pglobal_lookup symbol typically provided for > ). > > 5) kvm_open2() is like kvm_openfiles() except that it drops the unused > 'swapfile' argument and adds a new function pointer argument to a > symbol resolving function. The function pointer can be NULL in > which case only native kernels can be opened. Kernels used with > /dev/mem or /dev/kmem must be native. > > 6) kvm_read2() is like kvm_read() except that it uses kvaddr_t > instead of unsigned long for the kernel virtual address. All the above looks good... How will we prevent native only aware apps from getting confused when accessing non-native cores? Will kvm_openfiles fail for non-native cores? or will kvm_read fail for non-native cores? > Adding new symbols (specifically kvm_nlist2 and kvm_read2) preserves > ABI and API compatibility. Note that most libkvm functions such as > kvm_getprocs(), etc. only work with native kernels. I have not yet > done a full sweep to force them to fail for non-native kernels. For things like getprocs, we could move to using Lovasko's project to use ctf data to read the proc structures for non-native cores... Then the core parts of getprocs would not have to change, and it'd just work in all places.. > Also, the vnet and dpcpu stuff only works for native kernels currently > though that can be fixed at some point in the future. > > For the MD backends, I've added a new kvm_arch switch: > > struct kvm_arch { > int (*ka_probe)(kvm_t *); > int (*ka_initvtop)(kvm_t *); > void (*ka_freevtop)(kvm_t *); > int (*ka_kvatop)(kvm_t *, kvaddr_t, off_t *); > int (*ka_uvatop)(kvm_t *, const struct proc *, kvaddr_t, off_t *); > int ka_native; > }; > > Each backend implements the necessary callbacks (uvatop is optional) > and is added to a global linker set that kvm_open2() walks to find the > appropriate kvm_arch for a given kernel + vmcore. On x86 I've used > separate kvm_arch structures for "plain" vs minidumps. > > The backends now have to avoid using native headers. For ELF handling > this means using libelf instead of and raw mmap(). For > the x86 backends it meant defining some duplicate constants for certain > page table fields since can't be relied on (e.g. > I386_PG_V instead of PG_V). I added static assertions in the "native" > case (e.g. building kvm_i386.c on i386) to ensure the duplicate constants > match the originals. > > You can see the current WIP patches here: > > https://github.com/freebsd/freebsd/compare/master...bsdjhb:kgdb_enhancements > > What I'm mostly after is comments on the API, etc. Once that is settled I > will move forward on converting and/or stubbing the other backends (the > stub route would be to only support other backends on native systems for > now). You're API looks good... I can't see anything wrong w/ it... > Oh, and I do hope to have a 'KGDB' option for the devel/gdb port in the > near future. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Fri Aug 28 18:48:01 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFA5B9C5D73 for ; Fri, 28 Aug 2015 18:48:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 92DAD1EA7; Fri, 28 Aug 2015 18:48:01 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t7SIm0IP075980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2015 11:48:00 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t7SIm0I4075979; Fri, 28 Aug 2015 11:48:00 -0700 (PDT) (envelope-from jmg) Date: Fri, 28 Aug 2015 11:48:00 -0700 From: John-Mark Gurney To: Sean Bruno Cc: freebsd-arch@freebsd.org Subject: Re: Network card interrupt handling Message-ID: <20150828184800.GE33167@funkthat.com> References: <55DDE9B8.4080903@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <55DDE9B8.4080903@freebsd.org> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Fri, 28 Aug 2015 11:48:00 -0700 (PDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 18:48:01 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sean Bruno wrote this message on Wed, Aug 26, 2015 at 09:30 -0700: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > We've been diagnosing what appeared to be out of order processing in > the network stack this week only to find out that the network card > driver was shoveling bits to us out of order (em). > > This *seems* to be due to a design choice where the driver is allowed > to assert a "soft interrupt" to the h/w device while real interrupts > are disabled. This allows a fake "em_msix_rx" to be started *while* > "em_handle_que" is running from the taskqueue. We've isolated and > worked around this by setting our processing_limit in the driver to > - -1. This means that *most* packet processing is now handled in the > MSI-X handler instead of being deferred. Some periodic interference > is still detectable via em_local_timer() which causes one of these > "fake" interrupt assertions in the normal, card is *not* hung case. I have a better question, for MSI-X, we have a dedicated interrupt thread to do the processing, so why are we even doing any moderation in this case? It's not any different than spinning in the task queue.. How about the attached patch that just disables taskqueue processing for MSI-X RX interrupts, and does all processing in the interrupt thread? Do you need to add the rx_task to the em_local_timer? If so, then I would look at setting a flag in the _rxeof that says that processing is happening... and in the case of the taskqueue, when it sees this flag set, it just exits, while for the interrupt filter case, we'd need to be more careful (possibly set a flag that the taskqueue will inspect, and cause it to stop processing the rx queue)... > Both functions use identical code for a start. Both end up down > inside of em_rxeof() to process packets. Both drop the RX lock prior > to handing the data up the network stack. > > This means that the em_handle_que running from the taskqueue will be > preempted. Dtrace confirms that this allows out of order processing > to occur at times and generates a lot of resets. > > The reason I'm bringing this up on -arch and not on -net is that this > is a common design pattern in some of the Ethernet drivers. We've > done preliminary tests on a patch that moves *all* processing of RX > packets to the rx_task taskqueue, which means that em_handle_que is > now the only path to get packets processed. > > > https://people.freebsd.org/~sbruno/em_interupt_to_taskqueue.diff > > My sense is that this is a slightly "better" method to handle the > packets but removes some immediacy from packet processing since all > processing is deferred. However, all packet processing is now > serialized per queue, which I think is the proper implementation. > > Am I smoking "le dope" here or is this the way forward? I think you discovered an interresting issue.. btw, since you're hacking on em a lot, interrested in fixing em's jumbo frames so it doesn't use 9k clusters, but instead page sized clusters? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --pWyiEgJYm5f9v55/ Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="em.patch" diff --git a/sys/dev/e1000/if_em.c b/sys/dev/e1000/if_em.c index 830325b..b3c333a 100644 --- a/sys/dev/e1000/if_em.c +++ b/sys/dev/e1000/if_em.c @@ -1629,13 +1629,14 @@ em_msix_rx(void *arg) ++rxr->rx_irq; if (!(if_getdrvflags(adapter->ifp) & IFF_DRV_RUNNING)) return; - more = em_rxeof(rxr, adapter->rx_process_limit, NULL); - if (more) - taskqueue_enqueue(rxr->tq, &rxr->rx_task); - else { - /* Reenable this interrupt */ - E1000_WRITE_REG(&adapter->hw, E1000_IMS, rxr->ims); - } + + do { + more = em_rxeof(rxr, -1, NULL); + } while (more); + + /* Reenable this interrupt */ + E1000_WRITE_REG(&adapter->hw, E1000_IMS, rxr->ims); + return; } --pWyiEgJYm5f9v55/-- From owner-freebsd-arch@freebsd.org Fri Aug 28 19:04:34 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 283EA9C4373 for ; Fri, 28 Aug 2015 19:04:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (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 DE503A2D; Fri, 28 Aug 2015 19:04:33 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by ykek5 with SMTP id k5so11009954yke.3; Fri, 28 Aug 2015 12:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sBU2Xd/DpuZGtiWvHPJLgT7TjEowt9wJYXgQx4C2EgI=; b=OCd6nJwvMYXLeZzR7s0R5OemLwZM2qjlHffRAmImV7DLssObytmytPGKxuXfjXHR2Z bFUrk9EB4d4L5B5fcEaXz+y2jrw1Ewh3OFbfFdJzOjdCGfsMG0tBGs7ZDH0s2/HgQve3 mwQE8uoQOhp7bl0SunC7rFXLd8sqbQ88450Ui2+9q5ZxnM2/abKhD2Wl22fZX1NxSq8D esVpgfLGdSzkxsgkCHyCKfG/lw2otHH814aqre9VYlzKvgxH0LvPEyaS/2S1JczU2iDi SMbFj+ytBKbmXTIfmxaw5k7u6smOx4Tf+wWGd9p6BRVnXHmUiDFHDG2/Vo0HPCGhiVqa P0Zw== MIME-Version: 1.0 X-Received: by 10.129.133.67 with SMTP id v64mr9712551ywf.176.1440788672525; Fri, 28 Aug 2015 12:04:32 -0700 (PDT) Received: by 10.37.16.132 with HTTP; Fri, 28 Aug 2015 12:04:32 -0700 (PDT) In-Reply-To: <20150828184800.GE33167@funkthat.com> References: <55DDE9B8.4080903@freebsd.org> <20150828184800.GE33167@funkthat.com> Date: Fri, 28 Aug 2015 12:04:32 -0700 Message-ID: Subject: Re: Network card interrupt handling From: Jack Vogel To: John-Mark Gurney Cc: Sean Bruno , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 19:04:34 -0000 The reason the extra handling was added into the local timer was due to chasing hangs in the past, the thought was an interrupt may have been missed. Flags sound like a nice idea, but there is the possibility of a race condition and something still gets missed. Its been quite a few years ago, but there was a time when the em driver was having very intermittent hangs, in fact Sean may have been one of the victims, and this stuff was an attempt to solve that. Every time I looked at the em driver it just cried out to be thoroughly cleaned up or rewritten, but regression testing would be a pain doing that too. In any case, its no longer my job, and I'm glad Sean is giving it the attention he is :) Jack On Fri, Aug 28, 2015 at 11:48 AM, John-Mark Gurney wrote: > Sean Bruno wrote this message on Wed, Aug 26, 2015 at 09:30 -0700: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > We've been diagnosing what appeared to be out of order processing in > > the network stack this week only to find out that the network card > > driver was shoveling bits to us out of order (em). > > > > This *seems* to be due to a design choice where the driver is allowed > > to assert a "soft interrupt" to the h/w device while real interrupts > > are disabled. This allows a fake "em_msix_rx" to be started *while* > > "em_handle_que" is running from the taskqueue. We've isolated and > > worked around this by setting our processing_limit in the driver to > > - -1. This means that *most* packet processing is now handled in the > > MSI-X handler instead of being deferred. Some periodic interference > > is still detectable via em_local_timer() which causes one of these > > "fake" interrupt assertions in the normal, card is *not* hung case. > > I have a better question, for MSI-X, we have a dedicated interrupt > thread to do the processing, so why are we even doing any moderation > in this case? It's not any different than spinning in the task queue.. > > How about the attached patch that just disables taskqueue processing > for MSI-X RX interrupts, and does all processing in the interrupt > thread? > > Do you need to add the rx_task to the em_local_timer? If so, then > I would look at setting a flag in the _rxeof that says that processing > is happening... and in the case of the taskqueue, when it sees this > flag set, it just exits, while for the interrupt filter case, we'd > need to be more careful (possibly set a flag that the taskqueue will > inspect, and cause it to stop processing the rx queue)... > > > Both functions use identical code for a start. Both end up down > > inside of em_rxeof() to process packets. Both drop the RX lock prior > > to handing the data up the network stack. > > > > This means that the em_handle_que running from the taskqueue will be > > preempted. Dtrace confirms that this allows out of order processing > > to occur at times and generates a lot of resets. > > > > The reason I'm bringing this up on -arch and not on -net is that this > > is a common design pattern in some of the Ethernet drivers. We've > > done preliminary tests on a patch that moves *all* processing of RX > > packets to the rx_task taskqueue, which means that em_handle_que is > > now the only path to get packets processed. > > > > > > https://people.freebsd.org/~sbruno/em_interupt_to_taskqueue.diff > > > > My sense is that this is a slightly "better" method to handle the > > packets but removes some immediacy from packet processing since all > > processing is deferred. However, all packet processing is now > > serialized per queue, which I think is the proper implementation. > > > > Am I smoking "le dope" here or is this the way forward? > > I think you discovered an interresting issue.. > > btw, since you're hacking on em a lot, interrested in fixing em's > jumbo frames so it doesn't use 9k clusters, but instead page sized > clusters? > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@freebsd.org Fri Aug 28 19:41:37 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C4069C5119 for ; Fri, 28 Aug 2015 19:41:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 EDC1A1DCA; Fri, 28 Aug 2015 19:41:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igui7 with SMTP id i7so24060142igu.0; Fri, 28 Aug 2015 12:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5PtqWzKXjqQo1C17G0nMj77ReMG6R58sbSGce7436sQ=; b=tpXpN9lCTdF/jLzx91mavw/MpLSA/SkQPgCadb6L0OH8+EuhVr0Q4r4LetQy4eZ8La 19amgZVajkeG/YIuPTEy5x/s2xJjbkVYtKHiG1N7D9ojBjy7GQze0jGtjSKGHPudIwQp 4aZJMibvMV4v0n3zghccmOtJHa0oaMEUdCY19JuOYAIitrDxAKs4z4pM1bEh4nLNEWrB VyL/D17eEgpYJXyluNKrAcyyLfgF5MIhM9DprukXfdDg6GKtThqY/5tpOJEeNV41PYNb g9gSKSY2zSECaltj4hwQYNu08Cj/fz0ELypjECSJxuFa1xnQd5Y5bIUdPoOpHcrHwrMK wYjA== MIME-Version: 1.0 X-Received: by 10.50.62.193 with SMTP id a1mr4546504igs.61.1440790896322; Fri, 28 Aug 2015 12:41:36 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Fri, 28 Aug 2015 12:41:36 -0700 (PDT) In-Reply-To: References: <55DDE9B8.4080903@freebsd.org> <20150828184800.GE33167@funkthat.com> Date: Fri, 28 Aug 2015 12:41:36 -0700 Message-ID: Subject: Re: Network card interrupt handling From: Adrian Chadd To: Jack Vogel Cc: John-Mark Gurney , Sean Bruno , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 19:41:37 -0000 [snip] Well, the other big reason for doing it deferred like this is to avoid network based deadlocks because you're being fed packets faster than you can handle them. If you never yield, you stop other NIC processing. People used to do run-to-completion and then complained when this happened, so polling was a thing. So - I'm all for doing it with a fast interrupt handler and a fast taskqueue. As long as we don't run things to completion and re-schedule the taskqueue (so other things on that core get network processing) then I'm okay. (I kinda want us to have NAPI at some point...) -adrian From owner-freebsd-arch@freebsd.org Fri Aug 28 19:59:38 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 517C49C56D7 for ; Fri, 28 Aug 2015 19:59:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E207913 for ; Fri, 28 Aug 2015 19:59:38 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 44438B94B; Fri, 28 Aug 2015 15:59:37 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Marcel Moolenaar , Justin Hibbits Subject: Re: Devices with 36-bit paddr on 32-bit system Date: Fri, 28 Aug 2015 10:35:50 -0700 Message-ID: <1568331.OrSoeYfXsf@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 28 Aug 2015 15:59:37 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 19:59:38 -0000 On Tuesday, August 25, 2015 08:55:45 AM Marcel Moolenaar wrote: >=20 > > On Aug 24, 2015, at 11:44 PM, Justin Hibbits wrote: > >=20 > > With my work porting FreeBSD to PowerPC e500mc and e5500, I have > > devices in my device tree mapped well above the 4GB mark > > (0xffexxxxxx), and have no idea how to properly address them for > > resources in rman. Do we already have a solution to support this? > > Part of the problem is the powerpc nexus does a straight convert to= > > vm_offset_t of rman_get_start() (itself returning a u_long), and > > vm_offset_t is not necessarily equal to vm_paddr_t (on Book-E power= pc > > vm_offset_t is 32-bits, vm_paddr_t is 64-bits). >=20 > I think the best solution is to represent a resource address > space with a type other than u_long. It makes sense to have > it use bus_addr_t or vm_paddr_t for example. Such a change > comes at a high price for sure, but you=E2=80=99ll fix it once and > for all. I don=E2=80=99t think you should kluge your way out of this.= .. Expanding beyond u_long is the right solution. PAE doesn't generally s= uffer from this on i386 (though the ram0 device "punts" and ignores RAM range= s above 4G as a workaround). However, u_long is baked into the bus resource API quite a bit. Specif= ically, the values 0ul and ~0ul are used as magic numbers in lots of places to = request "anywhere" locations. Some of this has been mitigated by bus_alloc_resource_any(), but that doesn't cover all cases. You will p= robably want to add some explicit constants and do a sweep replacing the magic = numbers with those first (and MFC the constants at least to make it easier to p= ort drivers across branches). Then you can change the type. As far as the best type: rman's are in theory generic and not just for = bus addresses. I'd be tempted to let each platform define an rman_addr_t a= long with RMAN_ADDR_MAX constants, but in practice it is probably fine to us= e bus_addr_t and BUS_SPACE_MAXADDR. If you do that it also means you can= skip the step of having to MFC new constants. Note that various bus APIs will have to change to use bus_addr_t instea= d of u_long as well. --=20 John Baldwin From owner-freebsd-arch@freebsd.org Fri Aug 28 19:59:37 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7DB39C56D3 for ; Fri, 28 Aug 2015 19:59:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 871D5911; Fri, 28 Aug 2015 19:59:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D194AB93B; Fri, 28 Aug 2015 15:59:35 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Sean Bruno Subject: Re: Network card interrupt handling Date: Fri, 28 Aug 2015 10:38:36 -0700 Message-ID: <24017021.PxBoCiQKDJ@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <55DDE9B8.4080903@freebsd.org> References: <55DDE9B8.4080903@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 28 Aug 2015 15:59:35 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 19:59:37 -0000 On Wednesday, August 26, 2015 09:30:48 AM Sean Bruno wrote: > We've been diagnosing what appeared to be out of order processing in > the network stack this week only to find out that the network card > driver was shoveling bits to us out of order (em). > > This *seems* to be due to a design choice where the driver is allowed > to assert a "soft interrupt" to the h/w device while real interrupts > are disabled. This allows a fake "em_msix_rx" to be started *while* > "em_handle_que" is running from the taskqueue. We've isolated and > worked around this by setting our processing_limit in the driver to > -1. This means that *most* packet processing is now handled in the > MSI-X handler instead of being deferred. Some periodic interference > is still detectable via em_local_timer() which causes one of these > "fake" interrupt assertions in the normal, card is *not* hung case. > > Both functions use identical code for a start. Both end up down > inside of em_rxeof() to process packets. Both drop the RX lock prior > to handing the data up the network stack. > > This means that the em_handle_que running from the taskqueue will be > preempted. Dtrace confirms that this allows out of order processing > to occur at times and generates a lot of resets. > > The reason I'm bringing this up on -arch and not on -net is that this > is a common design pattern in some of the Ethernet drivers. We've > done preliminary tests on a patch that moves *all* processing of RX > packets to the rx_task taskqueue, which means that em_handle_que is > now the only path to get packets processed. It is only a common pattern in the Intel drivers. :-/ We (collectively) spent quite a while fixing this in ixgbe and igb. Longer (hopefully more like medium) term I have an update to the interrupt API I want to push in that allows drivers to manually schedule interrupt handlers using an 'hwi' API to replace the manual taskqueues. This also ensures that the handler that dequeues packets is only ever running in an ithread context and never concurrently. -- John Baldwin From owner-freebsd-arch@freebsd.org Fri Aug 28 20:52:54 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28EFE9C48D1 for ; Fri, 28 Aug 2015 20:52:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 071AB889 for ; Fri, 28 Aug 2015 20:52:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1ED79B93C; Fri, 28 Aug 2015 16:52:53 -0400 (EDT) From: John Baldwin To: John-Mark Gurney Cc: 'freebsd-arch' Subject: Re: Supporting cross-debugging vmcores in libkvm Date: Fri, 28 Aug 2015 13:39:31 -0700 Message-ID: <3887505.r5DL7PVlOf@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-PRERELEASE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20150828182705.GD33167@funkthat.com> References: <3121152.ujdxFEovO3@ralph.baldwin.cx> <20150828182705.GD33167@funkthat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 28 Aug 2015 16:52:53 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 20:52:54 -0000 On Friday, August 28, 2015 11:27:05 AM John-Mark Gurney wrote: > John Baldwin wrote this message on Tue, Aug 04, 2015 at 10:56 -0700: > How will we prevent native only aware apps from getting confused when > accessing non-native cores? Will kvm_openfiles fail for non-native > cores? or will kvm_read fail for non-native cores? kvm_openfiles() will fail. kvm_open2() will fail for a non-native core if a symbol resolving routine is not supplied. One API question I had is if it would be useful to allow a void * cookie to be passed to the symbol resolving routine (the same cookie would be passed to kvm_open2() and stored internally to be passed on each resolution request). I think in practice we don't need that level of complexity though (my kgdb changes did not). I will need to rebase this to port the arm64 minidump support over, but I also need people to test this. -- John Baldwin From owner-freebsd-arch@freebsd.org Fri Aug 28 20:59:35 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FA359C4B78 for ; Fri, 28 Aug 2015 20:59:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001: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 5B9FCCBC; Fri, 28 Aug 2015 20:59:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igph8 with SMTP id h8so19653552igp.0; Fri, 28 Aug 2015 13:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oorMlEat01N/AiCV1fYEkkQQXdufCr06LqrTbHPpJpg=; b=y65PoXP6rl5nwH6Ho09xyEzK9iCQuA+vvq6cDElY8UNIGxX5jnRxyVv5InGTg03/hF D0tfDX4aumQeaKxyfyJc6DLDevwn76dMWmzpxafzRDXSpF3UXQQ9mHwDgxy77oOXzD+N SSvK4OkvNfzk1I8tM0H1hKlz7jX6PdMduDZBWIeuIWApk5qC4NYwE16qz4id6kVhDZG9 4hUlvQRz3EIf/IWBqmt8aFXmSEo+3571vnj0eMz9T2hHbOYhf6uHP1/ZnXRmdpp1j8Q9 FKWSf3Tpvwo+R9lY3o8KpwwGcYg/xp2Kf1qsayIo9B0dg5VpySVDNbdxL1JhAZ+hdNu6 GHcg== MIME-Version: 1.0 X-Received: by 10.50.120.9 with SMTP id ky9mr4791154igb.61.1440795574209; Fri, 28 Aug 2015 13:59:34 -0700 (PDT) Received: by 10.36.28.208 with HTTP; Fri, 28 Aug 2015 13:59:34 -0700 (PDT) In-Reply-To: <1568331.OrSoeYfXsf@ralph.baldwin.cx> References: <1568331.OrSoeYfXsf@ralph.baldwin.cx> Date: Fri, 28 Aug 2015 13:59:34 -0700 Message-ID: Subject: Re: Devices with 36-bit paddr on 32-bit system From: Adrian Chadd To: John Baldwin Cc: "freebsd-arch@freebsd.org" , Justin Hibbits , Marcel Moolenaar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 20:59:35 -0000 +1 on this. Also - justin/i figured it out (well, I made the suggestion, he did the suggestion) which is just to do a big/single mapping of the relevant hardware window into vmem early in boot, and hack that bus nexus to treat things as being in that vmem region. He's gotten pretty far along the device bringup path now. That way the rmem allocation is just from that vmem region. -adrian On 28 August 2015 at 10:35, John Baldwin wrote: > On Tuesday, August 25, 2015 08:55:45 AM Marcel Moolenaar wrote: >> >> > On Aug 24, 2015, at 11:44 PM, Justin Hibbits w= rote: >> > >> > With my work porting FreeBSD to PowerPC e500mc and e5500, I have >> > devices in my device tree mapped well above the 4GB mark >> > (0xffexxxxxx), and have no idea how to properly address them for >> > resources in rman. Do we already have a solution to support this? >> > Part of the problem is the powerpc nexus does a straight convert to >> > vm_offset_t of rman_get_start() (itself returning a u_long), and >> > vm_offset_t is not necessarily equal to vm_paddr_t (on Book-E powerpc >> > vm_offset_t is 32-bits, vm_paddr_t is 64-bits). >> >> I think the best solution is to represent a resource address >> space with a type other than u_long. It makes sense to have >> it use bus_addr_t or vm_paddr_t for example. Such a change >> comes at a high price for sure, but you=E2=80=99ll fix it once and >> for all. I don=E2=80=99t think you should kluge your way out of this... > > Expanding beyond u_long is the right solution. PAE doesn't generally suf= fer > from this on i386 (though the ram0 device "punts" and ignores RAM ranges = above > 4G as a workaround). > > However, u_long is baked into the bus resource API quite a bit. Specific= ally, > the values 0ul and ~0ul are used as magic numbers in lots of places to re= quest > "anywhere" locations. Some of this has been mitigated by > bus_alloc_resource_any(), but that doesn't cover all cases. You will pro= bably > want to add some explicit constants and do a sweep replacing the magic nu= mbers > with those first (and MFC the constants at least to make it easier to por= t > drivers across branches). Then you can change the type. > > As far as the best type: rman's are in theory generic and not just for bu= s > addresses. I'd be tempted to let each platform define an rman_addr_t alo= ng > with RMAN_ADDR_MAX constants, but in practice it is probably fine to use > bus_addr_t and BUS_SPACE_MAXADDR. If you do that it also means you can s= kip > the step of having to MFC new constants. > > Note that various bus APIs will have to change to use bus_addr_t instead = of > u_long as well. > > -- > John Baldwin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Fri Aug 28 21:19:53 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4D599C5253 for ; Fri, 28 Aug 2015 21:19:53 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A8AF994; Fri, 28 Aug 2015 21:19:53 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t7SLJq8Q077555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Aug 2015 14:19:52 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t7SLJqYd077554; Fri, 28 Aug 2015 14:19:52 -0700 (PDT) (envelope-from jmg) Date: Fri, 28 Aug 2015 14:19:52 -0700 From: John-Mark Gurney To: John Baldwin Cc: "'freebsd-arch'" Subject: Re: Supporting cross-debugging vmcores in libkvm Message-ID: <20150828211952.GG33167@funkthat.com> References: <3121152.ujdxFEovO3@ralph.baldwin.cx> <20150828182705.GD33167@funkthat.com> <3887505.r5DL7PVlOf@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3887505.r5DL7PVlOf@ralph.baldwin.cx> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Fri, 28 Aug 2015 14:19:52 -0700 (PDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 21:19:53 -0000 John Baldwin wrote this message on Fri, Aug 28, 2015 at 13:39 -0700: > On Friday, August 28, 2015 11:27:05 AM John-Mark Gurney wrote: > > John Baldwin wrote this message on Tue, Aug 04, 2015 at 10:56 -0700: > > How will we prevent native only aware apps from getting confused when > > accessing non-native cores? Will kvm_openfiles fail for non-native > > cores? or will kvm_read fail for non-native cores? > > kvm_openfiles() will fail. kvm_open2() will fail for a non-native core > if a symbol resolving routine is not supplied. > > One API question I had is if it would be useful to allow a void * cookie > to be passed to the symbol resolving routine (the same cookie would be > passed to kvm_open2() and stored internally to be passed on each resolution > request). I think in practice we don't need that level of complexity > though (my kgdb changes did not). I can't think of a reason it would be required, but that doesn't mean someone else wouldn't need it... Though wouldn't the core parser provide the symbol lookup function? > I will need to rebase this to port the arm64 minidump support over, but > I also need people to test this. I'll see what I can do to help test it... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@freebsd.org Sat Aug 29 01:25:55 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2994F9C4B1B for ; Sat, 29 Aug 2015 01:25:55 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (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 00B79132; Sat, 29 Aug 2015 01:25:54 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by igph8 with SMTP id h8so23057354igp.0; Fri, 28 Aug 2015 18:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=faa25Yy0L1mM5x85u7lGzAoifVH9ZL5nEGFizINtNbE=; b=unGMNEXxxQlsw2is+cwS6/3wPoL8V0Zp4YKxUT+urhQVAmKMeN5kZwph/LAVHE85gE fwU1AbG9n1BP9ZM/iXbazMWvT56Xeooww+MHcjb1L4lw01PbcoJHsIKTAUcomjtCFjjM 314uRmXXVxkvuNCp+wJgYLwdBgaay0QdJjlJSnvZM7+FYBc2AUNipuuTlB6Eum14tfO1 SgXCLmbOGfF5FdI+q39iE4JI3IBCHQ+7MbST2yc3YAhSWkOw0841Ig/V8xlw1zx+1u5L DV/xAEtz8TWjZ+WYVmBHKKye6GXPBFq+5HYcJ4WxRM33ZBkMjE3dtMr9BpMz7xJIikV8 Mp9g== MIME-Version: 1.0 X-Received: by 10.50.50.129 with SMTP id c1mr6082172igo.60.1440811554161; Fri, 28 Aug 2015 18:25:54 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.36.30.202 with HTTP; Fri, 28 Aug 2015 18:25:53 -0700 (PDT) Received: by 10.36.30.202 with HTTP; Fri, 28 Aug 2015 18:25:53 -0700 (PDT) In-Reply-To: <24017021.PxBoCiQKDJ@ralph.baldwin.cx> References: <55DDE9B8.4080903@freebsd.org> <24017021.PxBoCiQKDJ@ralph.baldwin.cx> Date: Fri, 28 Aug 2015 18:25:53 -0700 X-Google-Sender-Auth: g06A6_w0-31zkSCoWOeCfnvvZco Message-ID: Subject: Re: Network card interrupt handling From: "K. Macy" To: John Baldwin Cc: freebsd-arch@freebsd.org, Sean Bruno Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 01:25:55 -0000 On Aug 28, 2015 12:59 PM, "John Baldwin" wrote: > > On Wednesday, August 26, 2015 09:30:48 AM Sean Bruno wrote: > > We've been diagnosing what appeared to be out of order processing in > > the network stack this week only to find out that the network card > > driver was shoveling bits to us out of order (em). > > > > This *seems* to be due to a design choice where the driver is allowed > > to assert a "soft interrupt" to the h/w device while real interrupts > > are disabled. This allows a fake "em_msix_rx" to be started *while* > > "em_handle_que" is running from the taskqueue. We've isolated and > > worked around this by setting our processing_limit in the driver to > > -1. This means that *most* packet processing is now handled in the > > MSI-X handler instead of being deferred. Some periodic interference > > is still detectable via em_local_timer() which causes one of these > > "fake" interrupt assertions in the normal, card is *not* hung case. > > > > Both functions use identical code for a start. Both end up down > > inside of em_rxeof() to process packets. Both drop the RX lock prior > > to handing the data up the network stack. > > > > This means that the em_handle_que running from the taskqueue will be > > preempted. Dtrace confirms that this allows out of order processing > > to occur at times and generates a lot of resets. > > > > The reason I'm bringing this up on -arch and not on -net is that this > > is a common design pattern in some of the Ethernet drivers. We've > > done preliminary tests on a patch that moves *all* processing of RX > > packets to the rx_task taskqueue, which means that em_handle_que is > > now the only path to get packets processed. > > It is only a common pattern in the Intel drivers. :-/ We (collectively) > spent quite a while fixing this in ixgbe and igb. Longer (hopefully more > like medium) term I have an update to the interrupt API I want to push in > that allows drivers to manually schedule interrupt handlers using an > 'hwi' API to replace the manual taskqueues. This also ensures that > the handler that dequeues packets is only ever running in an ithread > context and never concurrently. > Jeff has a generalization of the net_task infrastructure used at Nokia called grouptaskq that I've used for iflib. That does essentially what you refer to. I've converted ixl and am currently about to test an ixgbe conversion. I anticipate converting mlxen, all Intel drivers as well as the remaining drivers with device specific code in netmap. The one catch is finding someone who will publicly admit to owning re hardware so that I can buy it from him and test my changes. Cheers. From owner-freebsd-arch@freebsd.org Sat Aug 29 01:52:09 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BA659C540D for ; Sat, 29 Aug 2015 01:52:09 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 0D0C5DB5; Sat, 29 Aug 2015 01:52:09 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by padhm10 with SMTP id hm10so23518638pad.3; Fri, 28 Aug 2015 18:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aWLl3WQXG7BlsZuuSGQnV3NTGbW6glcLa0Pv61tcpO0=; b=0XWgNiiOeBLBiAu6F6oTEd3c6VrofFgjxCzg+4z8yvs2xeM89TsVNTVg3J/VZOAftD SWglexlbgUs/1Ozd6HM0QSKSY/PILMKjvZeo9IhZAyHVpmEm44iDjvhDKS4+V13T7Dq9 q6zdFLI1YSPHLSY648DUlhHVJi4zFe9IT3GSwdwBXqPVREyrPoK8J+TUSIqfQCx240An JtYZR1KPXDuPnqiD/87iwHXDGhzHL9Dg2HtF0f7EEyHLAJBdII9VHz+FyS5oliWejW99 xjZFji7GJHil2cU4U5BdHFW7NWR0yNlbf+7fwSURZ7llKG6OJiNhRoAMMvCgmkYr0dZW LApw== X-Received: by 10.66.162.162 with SMTP id yb2mr20166918pab.122.1440813128057; Fri, 28 Aug 2015 18:52:08 -0700 (PDT) Received: from [21.139.114.193] ([172.56.32.129]) by smtp.gmail.com with ESMTPSA id u1sm7077431pbz.56.2015.08.28.18.52.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Aug 2015 18:52:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Network card interrupt handling From: Garrett Cooper X-Mailer: iPhone Mail (12H321) In-Reply-To: Date: Fri, 28 Aug 2015 18:52:06 -0700 Cc: John Baldwin , Sean Bruno , "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <00E4073A-9AF4-4FAD-8C09-B771C26A8319@gmail.com> References: <55DDE9B8.4080903@freebsd.org> <24017021.PxBoCiQKDJ@ralph.baldwin.cx> To: "K. Macy" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 01:52:09 -0000 > On Aug 28, 2015, at 18:25, K. Macy wrote: >=20 >> On Aug 28, 2015 12:59 PM, "John Baldwin" wrote: >>=20 >>> On Wednesday, August 26, 2015 09:30:48 AM Sean Bruno wrote: >>> We've been diagnosing what appeared to be out of order processing in >>> the network stack this week only to find out that the network card >>> driver was shoveling bits to us out of order (em). >>>=20 >>> This *seems* to be due to a design choice where the driver is allowed >>> to assert a "soft interrupt" to the h/w device while real interrupts >>> are disabled. This allows a fake "em_msix_rx" to be started *while* >>> "em_handle_que" is running from the taskqueue. We've isolated and >>> worked around this by setting our processing_limit in the driver to >>> -1. This means that *most* packet processing is now handled in the >>> MSI-X handler instead of being deferred. Some periodic interference >>> is still detectable via em_local_timer() which causes one of these >>> "fake" interrupt assertions in the normal, card is *not* hung case. >>>=20 >>> Both functions use identical code for a start. Both end up down >>> inside of em_rxeof() to process packets. Both drop the RX lock prior >>> to handing the data up the network stack. >>>=20 >>> This means that the em_handle_que running from the taskqueue will be >>> preempted. Dtrace confirms that this allows out of order processing >>> to occur at times and generates a lot of resets. >>>=20 >>> The reason I'm bringing this up on -arch and not on -net is that this >>> is a common design pattern in some of the Ethernet drivers. We've >>> done preliminary tests on a patch that moves *all* processing of RX >>> packets to the rx_task taskqueue, which means that em_handle_que is >>> now the only path to get packets processed. >>=20 >> It is only a common pattern in the Intel drivers. :-/ We (collectively) >> spent quite a while fixing this in ixgbe and igb. Longer (hopefully more= >> like medium) term I have an update to the interrupt API I want to push in= >> that allows drivers to manually schedule interrupt handlers using an >> 'hwi' API to replace the manual taskqueues. This also ensures that >> the handler that dequeues packets is only ever running in an ithread >> context and never concurrently. >=20 > Jeff has a generalization of the net_task infrastructure used at Nokia > called grouptaskq that I've used for iflib. That does essentially what you= > refer to. I've converted ixl and am currently about to test an ixgbe > conversion. I anticipate converting mlxen, all Intel drivers as well as th= e > remaining drivers with device specific code in netmap. The one catch is > finding someone who will publicly admit to owning re hardware so that I ca= n > buy it from him and test my changes. >=20 > Cheers. I have 2 re NICs in my fileserver at home (Asus went cheap on some of their M= Bs a while back), but the cards shouldn't cost more than $15 + shipping (loo= k for "Realtek 8169" on Google). HTH! -NGie= From owner-freebsd-arch@freebsd.org Sat Aug 29 06:27:04 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98F589C5067 for ; Sat, 29 Aug 2015 06:27:04 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 66AC41EF7; Sat, 29 Aug 2015 06:27:04 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacdd16 with SMTP id dd16so83963881pac.2; Fri, 28 Aug 2015 23:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+X21TbfRJDP4MtfGlf2z9j5kkpjuRCswpuKvclYfk1U=; b=RWoX6IXzLbmo4/JlaKc8Lklv0b3O2ZYsM/cJY+qAK1FYNcvHdkCHmKQUlbz7qRwcYh OM/HhmeZ0E2cIC6gVpj5mMhADYLbsOQUP7llPivsw1e7YuhljCIctcd/H/48rlGIGztH MNu7gkVjDpk2hNaXP2DTUtA7az+3JMOIruya2BW3ODDPCZHKycAmEa+ioRsnjaWflm+Z VDIOfJNYFiWebdB4v5OkhbAGvEzsuCMch+36jl3AzSuXl2GwCBx/SbjZDHcHPvUo7f6L tIQW1dEDROkBflMGWG57xmIGLreBI7NzcVISnC+84B5rWyRP/IMfmgGtp97n21Jnt1MJ nlfQ== X-Received: by 10.68.111.165 with SMTP id ij5mr20722278pbb.59.1440829623945; Fri, 28 Aug 2015 23:27:03 -0700 (PDT) Received: from ?IPv6:2601:601:800:126d:d9d:ae1d:4add:6080? ([2601:601:800:126d:d9d:ae1d:4add:6080]) by smtp.gmail.com with ESMTPSA id bh5sm14645pbc.5.2015.08.28.23.27.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Aug 2015 23:27:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Network card interrupt handling From: Garrett Cooper In-Reply-To: <00E4073A-9AF4-4FAD-8C09-B771C26A8319@gmail.com> Date: Fri, 28 Aug 2015 23:27:02 -0700 Cc: John Baldwin , Sean Bruno , "freebsd-arch@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <29326C4E-9400-48A8-B4E5-F1B9997AC68F@gmail.com> References: <55DDE9B8.4080903@freebsd.org> <24017021.PxBoCiQKDJ@ralph.baldwin.cx> <00E4073A-9AF4-4FAD-8C09-B771C26A8319@gmail.com> To: "K. Macy" X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 06:27:04 -0000 > On Aug 28, 2015, at 18:52, Garrett Cooper = wrote: =E2=80=A6 > I have 2 re NICs in my fileserver at home (Asus went cheap on some of = their MBs a while back), but the cards shouldn't cost more than $15 + = shipping (look for "Realtek 8169" on Google). QEMU also emulates re(4) too, depending on what NIC you ask for at boot. Cheers, -NGie= From owner-freebsd-arch@freebsd.org Sat Aug 29 18:35:48 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 459889C5704 for ; Sat, 29 Aug 2015 18:35:48 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 02B4E334; Sat, 29 Aug 2015 18:35:48 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by ioej130 with SMTP id j130so40884806ioe.3; Sat, 29 Aug 2015 11:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RLljBotrRlvxhbTPVmCNiN5Yd7EeLrUnjMui668Mmnk=; b=gcQk7zpuLMt3x2TawSUFnTVz6aO8mTDJdCD1ldsRhzCCOZGH3tfwp6K53KIhXLZ80Z bcrWEF1/wibNgHL6an+U0vAiTBoZlBFPuAEW/tE7IVRkZ9O8IqU/UktA4cCkpQvlHRJO 3OEeCdwhqlCFeBb5uqnDFAoJKqQaqdLF05q2sCbu5VFMxeZWbwyzYLDk1h74nEWTOB5W 9i9Oz2OGmmorp/tYbZZmp7miNx7AZCQHId7Uen2FWPq9s+C285no3ZufiGupdfVkWmNt tLcr+a7D80zmeFChO7Eo62vpsED2wioC73jQZ5oNJ26chrZcUsK5to1xMXWM0lJAnMB+ BXAg== MIME-Version: 1.0 X-Received: by 10.107.167.199 with SMTP id q190mr22741089ioe.119.1440873347319; Sat, 29 Aug 2015 11:35:47 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.36.58.149 with HTTP; Sat, 29 Aug 2015 11:35:47 -0700 (PDT) In-Reply-To: References: <1568331.OrSoeYfXsf@ralph.baldwin.cx> Date: Sat, 29 Aug 2015 11:35:47 -0700 X-Google-Sender-Auth: ljK1pwWT12zjsyEJzb8v4Eg7-mw Message-ID: Subject: Re: Devices with 36-bit paddr on 32-bit system From: Justin Hibbits To: Adrian Chadd Cc: John Baldwin , "freebsd-arch@freebsd.org" , Marcel Moolenaar Content-Type: multipart/mixed; boundary=001a1141f3be08c46f051e777817 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 18:35:48 -0000 --001a1141f3be08c46f051e777817 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey, I already had that thought, too, you just encouraged me to take it :) Anyway, here's an initial patch. I've *only* tested it on one PowerPC board (the one needing this change), none of my other devices, and no other architectures. Thoughts? tl;dr I went with using bus_addr_t for the addresses, and kept u_long for the sizes (I can change it to use bus_size_t instead, but it's already vm_offset_t on PowerPC, which is long anyway). Since I took the diff as a whole, and erased unrelated bits, there may still be unrelated bits in the diff, which can be ignored (all part of my larger work). - Justin On Fri, Aug 28, 2015 at 1:59 PM, Adrian Chadd wrot= e: > +1 on this. > > Also - justin/i figured it out (well, I made the suggestion, he did > the suggestion) which is just to do a big/single mapping of the > relevant hardware window into vmem early in boot, and hack that bus > nexus to treat things as being in that vmem region. He's gotten pretty > far along the device bringup path now. That way the rmem allocation is > just from that vmem region. > > > > -adrian > > > > On 28 August 2015 at 10:35, John Baldwin wrote: >> On Tuesday, August 25, 2015 08:55:45 AM Marcel Moolenaar wrote: >>> >>> > On Aug 24, 2015, at 11:44 PM, Justin Hibbits = wrote: >>> > >>> > With my work porting FreeBSD to PowerPC e500mc and e5500, I have >>> > devices in my device tree mapped well above the 4GB mark >>> > (0xffexxxxxx), and have no idea how to properly address them for >>> > resources in rman. Do we already have a solution to support this? >>> > Part of the problem is the powerpc nexus does a straight convert to >>> > vm_offset_t of rman_get_start() (itself returning a u_long), and >>> > vm_offset_t is not necessarily equal to vm_paddr_t (on Book-E powerpc >>> > vm_offset_t is 32-bits, vm_paddr_t is 64-bits). >>> >>> I think the best solution is to represent a resource address >>> space with a type other than u_long. It makes sense to have >>> it use bus_addr_t or vm_paddr_t for example. Such a change >>> comes at a high price for sure, but you=E2=80=99ll fix it once and >>> for all. I don=E2=80=99t think you should kluge your way out of this... >> >> Expanding beyond u_long is the right solution. PAE doesn't generally su= ffer >> from this on i386 (though the ram0 device "punts" and ignores RAM ranges= above >> 4G as a workaround). >> >> However, u_long is baked into the bus resource API quite a bit. Specifi= cally, >> the values 0ul and ~0ul are used as magic numbers in lots of places to r= equest >> "anywhere" locations. Some of this has been mitigated by >> bus_alloc_resource_any(), but that doesn't cover all cases. You will pr= obably >> want to add some explicit constants and do a sweep replacing the magic n= umbers >> with those first (and MFC the constants at least to make it easier to po= rt >> drivers across branches). Then you can change the type. >> >> As far as the best type: rman's are in theory generic and not just for b= us >> addresses. I'd be tempted to let each platform define an rman_addr_t al= ong >> with RMAN_ADDR_MAX constants, but in practice it is probably fine to use >> bus_addr_t and BUS_SPACE_MAXADDR. If you do that it also means you can = skip >> the step of having to MFC new constants. >> >> Note that various bus APIs will have to change to use bus_addr_t instead= of >> u_long as well. >> >> -- >> John Baldwin >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" --001a1141f3be08c46f051e777817 Content-Type: text/plain; charset=US-ASCII; name="rman.diff" Content-Disposition: attachment; filename="rman.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_idxeo38y0 SW5kZXg6IHN5cy9kZXYvYXRhL2F0YS1wY2kuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L2F0YS9h dGEtcGNpLmMJKHJldmlzaW9uIDI4NzE4OSkKKysrIHN5cy9kZXYvYXRhL2F0YS1wY2kuYwkod29y a2luZyBjb3B5KQpAQCAtMjE3LDcgKzIxNyw3IEBACiAKIHN0cnVjdCByZXNvdXJjZSAqCiBhdGFf cGNpX2FsbG9jX3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBl LCBpbnQgKnJpZCwKLQkJICAgICAgIHVfbG9uZyBzdGFydCwgdV9sb25nIGVuZCwgdV9sb25nIGNv dW50LCB1X2ludCBmbGFncykKKwkJICAgICAgIGJ1c19hZGRyX3Qgc3RhcnQsIGJ1c19hZGRyX3Qg ZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKQogewogCXN0cnVjdCBhdGFfcGNpX2NvbnRy b2xsZXIgKmNvbnRyb2xsZXIgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAJc3RydWN0IHJlc291 cmNlICpyZXMgPSBOVUxMOwpJbmRleDogc3lzL2Rldi9hdGEvYXRhLXBjaS5oCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHN5cy9kZXYvYXRhL2F0YS1wY2kuaAkocmV2aXNpb24gMjg3MTg5KQorKysgc3lzL2Rldi9h dGEvYXRhLXBjaS5oCSh3b3JraW5nIGNvcHkpCkBAIC01MzUsNyArNTM1LDcgQEAKIGludCBhdGFf cGNpX3ByaW50X2NoaWxkKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQpOwogaW50IGF0YV9w Y2lfY2hpbGRfbG9jYXRpb25fc3RyKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGNoYXIg KmJ1ZiwKICAgICBzaXplX3QgYnVmbGVuKTsKLXN0cnVjdCByZXNvdXJjZSAqIGF0YV9wY2lfYWxs b2NfcmVzb3VyY2UoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAq cmlkLCB1X2xvbmcgc3RhcnQsIHVfbG9uZyBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3Mp Oworc3RydWN0IHJlc291cmNlICogYXRhX3BjaV9hbGxvY19yZXNvdXJjZShkZXZpY2VfdCBkZXYs IGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50ICpyaWQsIGJ1c19hZGRyX3Qgc3RhcnQsIGJ1 c19hZGRyX3QgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKTsKIGludCBhdGFfcGNpX3Jl bGVhc2VfcmVzb3VyY2UoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGlu dCByaWQsIHN0cnVjdCByZXNvdXJjZSAqcik7CiBpbnQgYXRhX3BjaV9zZXR1cF9pbnRyKGRldmlj ZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIHN0cnVjdCByZXNvdXJjZSAqaXJxLCBpbnQgZmxhZ3Ms IGRyaXZlcl9maWx0ZXJfdCAqZmlsdGVyLCBkcml2ZXJfaW50cl90ICpmdW5jdGlvbiwgdm9pZCAq YXJndW1lbnQsIHZvaWQgKipjb29raWVwKTsKICBpbnQgYXRhX3BjaV90ZWFyZG93bl9pbnRyKGRl dmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIHN0cnVjdCByZXNvdXJjZSAqaXJxLCB2b2lkICpj b29raWUpOwpJbmRleDogc3lzL2Rldi9hdGEvY2hpcHNldHMvYXRhLXByb21pc2UuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBzeXMvZGV2L2F0YS9jaGlwc2V0cy9hdGEtcHJvbWlzZS5jCShyZXZpc2lvbiAyODcx ODkpCisrKyBzeXMvZGV2L2F0YS9jaGlwc2V0cy9hdGEtcHJvbWlzZS5jCSh3b3JraW5nIGNvcHkp CkBAIC0xOTEsMTggKzE5MSwxOSBAQAogCSFCVVNfUkVBRF9JVkFSKGRldmljZV9nZXRfcGFyZW50 KEdSQU5EUEFSRU5UKGRldikpLAogCQkgICAgICAgR1JBTkRQQVJFTlQoZGV2KSwgUENJX0lWQVJf REVWSUQsICZkZXZpZCkgJiYKIAkoKGRldmlkID09IEFUQV9ERUNfMjExNTApIHx8IChkZXZpZCA9 PSBBVEFfREVDXzIxMTUwXzEpKSkgewotCXN0YXRpYyBsb25nIHN0YXJ0ID0gMCwgZW5kID0gMDsK KwlzdGF0aWMgYnVzX2FkZHJfdCBzdGFydCA9IDA7CisJc3RhdGljIHVfbG9uZyBjb3VudCA9IDA7 CiAKIAlpZiAocGNpX2dldF9zbG90KGRldikgPT0gMSkgewotCSAgICBidXNfZ2V0X3Jlc291cmNl KGRldiwgU1lTX1JFU19JUlEsIDAsICZzdGFydCwgJmVuZCk7CisJICAgIGJ1c19nZXRfcmVzb3Vy Y2UoZGV2LCBTWVNfUkVTX0lSUSwgMCwgJnN0YXJ0LCAmY291bnQpOwogCSAgICBzdHJjYXQoYnVm ZmVyLCAiIChjaGFubmVsIDArMSkiKTsKIAl9Ci0JZWxzZSBpZiAocGNpX2dldF9zbG90KGRldikg PT0gMiAmJiBzdGFydCAmJiBlbmQpIHsKLQkgICAgYnVzX3NldF9yZXNvdXJjZShkZXYsIFNZU19S RVNfSVJRLCAwLCBzdGFydCwgZW5kKTsKKwllbHNlIGlmIChwY2lfZ2V0X3Nsb3QoZGV2KSA9PSAy ICYmIHN0YXJ0ICYmIGNvdW50KSB7CisJICAgIGJ1c19zZXRfcmVzb3VyY2UoZGV2LCBTWVNfUkVT X0lSUSwgMCwgc3RhcnQsIGNvdW50KTsKIAkgICAgc3RyY2F0KGJ1ZmZlciwgIiAoY2hhbm5lbCAy KzMpIik7CiAJfQogCWVsc2UgewotCSAgICBzdGFydCA9IGVuZCA9IDA7CisJICAgIHN0YXJ0ID0g Y291bnQgPSAwOwogCX0KICAgICB9CiAgICAgc3ByaW50ZihidWZmZXIsICIlcyAlcyBjb250cm9s bGVyIiwgYnVmZmVyLCBhdGFfbW9kZTJzdHIoaWR4LT5tYXhfZG1hKSk7CkluZGV4OiBzeXMvZGV2 L2ZkdC9zaW1wbGVidXMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L2ZkdC9zaW1wbGVidXMuYwko cmV2aXNpb24gMjg3MTg5KQorKysgc3lzL2Rldi9mZHQvc2ltcGxlYnVzLmMJKHdvcmtpbmcgY29w eSkKQEAgLTQ2LDcgKzQ2LDcgQEAKIHN0YXRpYyBpbnQJCXNpbXBsZWJ1c19wcm9iZShkZXZpY2Vf dCBkZXYpOwogc3RhdGljIGludAkJc2ltcGxlYnVzX2F0dGFjaChkZXZpY2VfdCBkZXYpOwogc3Rh dGljIHN0cnVjdCByZXNvdXJjZSAqc2ltcGxlYnVzX2FsbG9jX3Jlc291cmNlKGRldmljZV90LCBk ZXZpY2VfdCwgaW50LAotICAgIGludCAqLCB1X2xvbmcsIHVfbG9uZywgdV9sb25nLCB1X2ludCk7 CisgICAgaW50ICosIGJ1c19hZGRyX3QsIGJ1c19hZGRyX3QsIHVfbG9uZywgdV9pbnQpOwogc3Rh dGljIHZvaWQJCXNpbXBsZWJ1c19wcm9iZV9ub21hdGNoKGRldmljZV90IGJ1cywgZGV2aWNlX3Qg Y2hpbGQpOwogc3RhdGljIGludAkJc2ltcGxlYnVzX3ByaW50X2NoaWxkKGRldmljZV90IGJ1cywg ZGV2aWNlX3QgY2hpbGQpOwogc3RhdGljIGRldmljZV90CQlzaW1wbGVidXNfYWRkX2NoaWxkKGRl dmljZV90IGRldiwgdV9pbnQgb3JkZXIsCkBAIC0zMTgsNyArMzE4LDcgQEAKIAogc3RhdGljIHN0 cnVjdCByZXNvdXJjZSAqCiBzaW1wbGVidXNfYWxsb2NfcmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBk ZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlkLAotICAgIHVfbG9uZyBzdGFydCwgdV9s b25nIGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKKyAgICBidXNfYWRkcl90IHN0YXJ0 LCBidXNfYWRkcl90IGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKIHsKIAlzdHJ1Y3Qg c2ltcGxlYnVzX3NvZnRjICpzYzsKIAlzdHJ1Y3Qgc2ltcGxlYnVzX2RldmluZm8gKmRpOwpAQCAt MzMxLDcgKzMzMSw3IEBACiAJICogUmVxdWVzdCBmb3IgdGhlIGRlZmF1bHQgYWxsb2NhdGlvbiB3 aXRoIGEgZ2l2ZW4gcmlkOiB1c2UgcmVzb3VyY2UKIAkgKiBsaXN0IHN0b3JlZCBpbiB0aGUgbG9j YWwgZGV2aWNlIGluZm8uCiAJICovCi0JaWYgKChzdGFydCA9PSAwVUwpICYmIChlbmQgPT0gfjBV TCkpIHsKKwlpZiAoKHN0YXJ0ID09IFJNX01JTl9TVEFSVCkgJiYgKGVuZCA9PSBSTV9NQVhfRU5E KSkgewogCQlpZiAoKGRpID0gZGV2aWNlX2dldF9pdmFycyhjaGlsZCkpID09IE5VTEwpCiAJCQly ZXR1cm4gKE5VTEwpOwogCkBAIC0zNjUsNyArMzY1LDggQEAKIAkJaWYgKGogPT0gc2MtPm5yYW5n ZXMgJiYgc2MtPm5yYW5nZXMgIT0gMCkgewogCQkJaWYgKGJvb3R2ZXJib3NlKQogCQkJCWRldmlj ZV9wcmludGYoYnVzLCAiQ291bGQgbm90IG1hcCByZXNvdXJjZSAiCi0JCQkJICAgICIlI2x4LSUj bHhcbiIsIHN0YXJ0LCBlbmQpOworCQkJCSAgICAiJSNsbHgtJSNsbHhcbiIsICh1aW50NjRfdClz dGFydCwKKwkJCQkgICAgKHVpbnQ2NF90KWVuZCk7CiAKIAkJCXJldHVybiAoTlVMTCk7CiAJCX0K QEAgLTM4MSw4ICszODIsOCBAQAogCWludCBydjsKIAogCXJ2ID0gMDsKLQlydiArPSByZXNvdXJj ZV9saXN0X3ByaW50X3R5cGUoJmRpLT5ybCwgIm1lbSIsIFNZU19SRVNfTUVNT1JZLCAiJSNseCIp OwotCXJ2ICs9IHJlc291cmNlX2xpc3RfcHJpbnRfdHlwZSgmZGktPnJsLCAiaXJxIiwgU1lTX1JF U19JUlEsICIlbGQiKTsKKwlydiArPSByZXNvdXJjZV9saXN0X3ByaW50X3R5cGUoJmRpLT5ybCwg Im1lbSIsIFNZU19SRVNfTUVNT1JZLCAiJSNsbHgiKTsKKwlydiArPSByZXNvdXJjZV9saXN0X3By aW50X3R5cGUoJmRpLT5ybCwgImlycSIsIFNZU19SRVNfSVJRLCAiJWxsZCIpOwogCXJldHVybiAo cnYpOwogfQogCkluZGV4OiBzeXMvZGV2L2dwaW8vZ3Bpb2J1cy5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5 cy9kZXYvZ3Bpby9ncGlvYnVzLmMJKHJldmlzaW9uIDI4NzE4OSkKKysrIHN5cy9kZXYvZ3Bpby9n cGlvYnVzLmMJKHdvcmtpbmcgY29weSkKQEAgLTE3OCw3ICsxNzgsNyBAQAogCXNjLT5zY19pbnRy X3JtYW4ucm1fdHlwZSA9IFJNQU5fQVJSQVk7CiAJc2MtPnNjX2ludHJfcm1hbi5ybV9kZXNjciA9 ICJHUElPIEludGVycnVwdHMiOwogCWlmIChybWFuX2luaXQoJnNjLT5zY19pbnRyX3JtYW4pICE9 IDAgfHwKLQkgICAgcm1hbl9tYW5hZ2VfcmVnaW9uKCZzYy0+c2NfaW50cl9ybWFuLCAwLCB+MCkg IT0gMCkKKwkgICAgcm1hbl9tYW5hZ2VfcmVnaW9uKCZzYy0+c2NfaW50cl9ybWFuLCAwLCB+KGJ1 c19hZGRyX3QpMCkgIT0gMCkKIAkJcGFuaWMoIiVzOiBmYWlsZWQgdG8gc2V0IHVwIHJtYW4uIiwg X19mdW5jX18pOwogCiAJaWYgKEdQSU9fUElOX01BWChzYy0+c2NfZGV2LCAmc2MtPnNjX25waW5z KSAhPSAwKQpAQCAtNDg4LDcgKzQ4OCw3IEBACiAKIHN0YXRpYyBpbnQKIGdwaW9idXNfc2V0X3Jl c291cmNlKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlkLAot ICAgIHVfbG9uZyBzdGFydCwgdV9sb25nIGNvdW50KQorICAgIGJ1c19hZGRyX3Qgc3RhcnQsIHVf bG9uZyBjb3VudCkKIHsKIAlzdHJ1Y3QgZ3Bpb2J1c19pdmFyICpkZXZpOwogCXN0cnVjdCByZXNv dXJjZV9saXN0X2VudHJ5ICpybGU7CkBAIC01MDYsNyArNTA2LDcgQEAKIAogc3RhdGljIHN0cnVj dCByZXNvdXJjZSAqCiBncGlvYnVzX2FsbG9jX3Jlc291cmNlKGRldmljZV90IGJ1cywgZGV2aWNl X3QgY2hpbGQsIGludCB0eXBlLCBpbnQgKnJpZCwKLSAgICB1X2xvbmcgc3RhcnQsIHVfbG9uZyBl bmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCisgICAgYnVzX2FkZHJfdCBzdGFydCwgYnVz X2FkZHJfdCBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCiB7CiAJc3RydWN0IGdwaW9i dXNfc29mdGMgKnNjOwogCXN0cnVjdCByZXNvdXJjZSAqcnY7CkBAIC01MTYsNyArNTE2LDcgQEAK IAogCWlmICh0eXBlICE9IFNZU19SRVNfSVJRKQogCQlyZXR1cm4gKE5VTEwpOwotCWlzZGVmYXVs dCA9IChzdGFydCA9PSAwVUwgJiYgZW5kID09IH4wVUwgJiYgY291bnQgPT0gMSk7CisJaXNkZWZh dWx0ID0gKHN0YXJ0ID09IDBVTCAmJiBlbmQgPT0gfihidXNfYWRkcl90KTBVTCAmJiBjb3VudCA9 PSAxKTsKIAlybGUgPSBOVUxMOwogCWlmIChpc2RlZmF1bHQpIHsKIAkJcmwgPSBCVVNfR0VUX1JF U09VUkNFX0xJU1QoYnVzLCBjaGlsZCk7CkluZGV4OiBzeXMvZGV2L29mdy9vZndidXMuYwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBzeXMvZGV2L29mdy9vZndidXMuYwkocmV2aXNpb24gMjg3MTg5KQorKysgc3lz L2Rldi9vZncvb2Z3YnVzLmMJKHdvcmtpbmcgY29weSkKQEAgLTE1Niw3ICsxNTYsNyBAQAogCXNj LT5zY19tZW1fcm1hbi5ybV9kZXNjciA9ICJEZXZpY2UgTWVtb3J5IjsKIAlpZiAocm1hbl9pbml0 KCZzYy0+c2NfaW50cl9ybWFuKSAhPSAwIHx8CiAJICAgIHJtYW5faW5pdCgmc2MtPnNjX21lbV9y bWFuKSAhPSAwIHx8Ci0JICAgIHJtYW5fbWFuYWdlX3JlZ2lvbigmc2MtPnNjX2ludHJfcm1hbiwg MCwgfjApICE9IDAgfHwKKwkgICAgcm1hbl9tYW5hZ2VfcmVnaW9uKCZzYy0+c2NfaW50cl9ybWFu LCAwLCBCVVNfU1BBQ0VfTUFYQUREUikgIT0gMCB8fAogCSAgICBybWFuX21hbmFnZV9yZWdpb24o JnNjLT5zY19tZW1fcm1hbiwgMCwgQlVTX1NQQUNFX01BWEFERFIpICE9IDApCiAJCXBhbmljKCIl czogZmFpbGVkIHRvIHNldCB1cCBybWFucy4iLCBfX2Z1bmNfXyk7CiAKQEAgLTE3OCw3ICsxNzgs NyBAQAogCiBzdGF0aWMgc3RydWN0IHJlc291cmNlICoKIG9md2J1c19hbGxvY19yZXNvdXJjZShk ZXZpY2VfdCBidXMsIGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50ICpyaWQsCi0gICAgdV9s b25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKQorICAgIGJ1 c19hZGRyX3Qgc3RhcnQsIGJ1c19hZGRyX3QgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdz KQogewogCXN0cnVjdCBvZndidXNfc29mdGMgKnNjOwogCXN0cnVjdCBybWFuICpybTsKQEAgLTE4 Niw3ICsxODYsNyBAQAogCXN0cnVjdCByZXNvdXJjZV9saXN0X2VudHJ5ICpybGU7CiAJaW50IGlz ZGVmYXVsdCwgcGFzc3Rocm91Z2g7CiAKLQlpc2RlZmF1bHQgPSAoc3RhcnQgPT0gMFVMICYmIGVu ZCA9PSB+MFVMKTsKKwlpc2RlZmF1bHQgPSAoc3RhcnQgPT0gUk1fTUlOX1NUQVJUICYmIGVuZCA9 PSBSTV9NQVhfRU5EKTsKIAlwYXNzdGhyb3VnaCA9IChkZXZpY2VfZ2V0X3BhcmVudChjaGlsZCkg IT0gYnVzKTsKIAlzYyA9IGRldmljZV9nZXRfc29mdGMoYnVzKTsKIAlybGUgPSBOVUxMOwpAQCAt MjAxLDcgKzIwMSw3IEBACiAJCX0KIAkJc3RhcnQgPSBybGUtPnN0YXJ0OwogCQljb3VudCA9IHVs bWF4KGNvdW50LCBybGUtPmNvdW50KTsKLQkJZW5kID0gdWxtYXgocmxlLT5lbmQsIHN0YXJ0ICsg Y291bnQgLSAxKTsKKwkJZW5kID0gcW1heChybGUtPmVuZCwgc3RhcnQgKyBjb3VudCAtIDEpOwog CX0KIAogCXN3aXRjaCAodHlwZSkgewpAQCAtMjM5LDcgKzIzOSw3IEBACiAKIHN0YXRpYyBpbnQK IG9md2J1c19hZGp1c3RfcmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCBfX3Vu dXNlZCwgaW50IHR5cGUsCi0gICAgc3RydWN0IHJlc291cmNlICpyLCB1X2xvbmcgc3RhcnQsIHVf bG9uZyBlbmQpCisgICAgc3RydWN0IHJlc291cmNlICpyLCBidXNfYWRkcl90IHN0YXJ0LCBidXNf YWRkcl90IGVuZCkKIHsKIAlzdHJ1Y3Qgb2Z3YnVzX3NvZnRjICpzYzsKIAlzdHJ1Y3Qgcm1hbiAq cm07CkluZGV4OiBzeXMvZGV2L3BjaS9ob3N0Yl9wY2kuYwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2 L3BjaS9ob3N0Yl9wY2kuYwkocmV2aXNpb24gMjg3MTg5KQorKysgc3lzL2Rldi9wY2kvaG9zdGJf cGNpLmMJKHdvcmtpbmcgY29weSkKQEAgLTEwMiw3ICsxMDIsNyBAQAogCiBzdGF0aWMgc3RydWN0 IHJlc291cmNlICoKIHBjaV9ob3N0Yl9hbGxvY19yZXNvdXJjZShkZXZpY2VfdCBkZXYsIGRldmlj ZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50ICpyaWQsCi0gICAgdV9sb25nIHN0YXJ0LCB1X2xvbmcg ZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKQorICAgIGJ1c19hZGRyX3Qgc3RhcnQsIGJ1 c19hZGRyX3QgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKQogewogCiAJcmV0dXJuIChi dXNfYWxsb2NfcmVzb3VyY2UoZGV2LCB0eXBlLCByaWQsIHN0YXJ0LCBlbmQsIGNvdW50LCBmbGFn cykpOwpJbmRleDogc3lzL2Rldi9wY2kvcGNpLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9wY2kv cGNpLmMJKHJldmlzaW9uIDI4NzE4OSkKKysrIHN5cy9kZXYvcGNpL3BjaS5jCSh3b3JraW5nIGNv cHkpCkBAIC00NzEwLDcgKzQ3MTAsNyBAQAogCiBzdHJ1Y3QgcmVzb3VyY2UgKgogcGNpX2FsbG9j X3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgKnJp ZCwKLSAgICB1X2xvbmcgc3RhcnQsIHVfbG9uZyBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxh Z3MpCisgICAgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQsIHVfbG9uZyBjb3VudCwg dV9pbnQgZmxhZ3MpCiB7CiAjaWZkZWYgUENJX0lPVgogCXN0cnVjdCBwY2lfZGV2aW5mbyAqZGlu Zm87CkluZGV4OiBzeXMvZGV2L3BjaS9wY2lfcGNpLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9w Y2kvcGNpX3BjaS5jCShyZXZpc2lvbiAyODcxODkpCisrKyBzeXMvZGV2L3BjaS9wY2lfcGNpLmMJ KHdvcmtpbmcgY29weSkKQEAgLTIxMiw5ICsyMTIsMTAgQEAKICAqIElTQSBhbGlhcyByYW5nZS4K ICAqLwogc3RhdGljIGludAotcGNpYl9pc19pc2FfcmFuZ2Uoc3RydWN0IHBjaWJfc29mdGMgKnNj LCB1X2xvbmcgc3RhcnQsIHVfbG9uZyBlbmQsIHVfbG9uZyBjb3VudCkKK3BjaWJfaXNfaXNhX3Jh bmdlKHN0cnVjdCBwY2liX3NvZnRjICpzYywgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBl bmQsCisgICAgdV9sb25nIGNvdW50KQogewotCXVfbG9uZyBuZXh0X2FsaWFzOworCWJ1c19hZGRy X3QgbmV4dF9hbGlhczsKIAogCWlmICghKHNjLT5icmlkZ2VjdGwgJiBQQ0lCX0JDUl9JU0FfRU5B QkxFKSkKIAkJcmV0dXJuICgwKTsKQEAgLTI3NSwxMyArMjc2LDEzIEBACiAJfQogfQogCi10eXBl ZGVmIHZvaWQgKG5vbmlzYV9jYWxsYmFjaykodV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB2b2lk ICphcmcpOwordHlwZWRlZiB2b2lkIChub25pc2FfY2FsbGJhY2spKGJ1c19hZGRyX3Qgc3RhcnQs IGJ1c19hZGRyX3QgZW5kLCB2b2lkICphcmcpOwogCiBzdGF0aWMgdm9pZAotcGNpYl93YWxrX25v bmlzYV9yYW5nZXModV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCBub25pc2FfY2FsbGJhY2sgKmNi LAorcGNpYl93YWxrX25vbmlzYV9yYW5nZXMoYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBl bmQsIG5vbmlzYV9jYWxsYmFjayAqY2IsCiAgICAgdm9pZCAqYXJnKQogewotCXVfbG9uZyBuZXh0 X2VuZDsKKwlidXNfYWRkcl90IG5leHRfZW5kOwogCiAJLyoKIAkgKiBJZiBzdGFydCBpcyB3aXRo aW4gYW4gSVNBIGFsaWFzIHJhbmdlLCBtb3ZlIHVwIHRvIHRoZSBzdGFydApAQCAtMzA5LDcgKzMx MCw3IEBACiB9CiAKIHN0YXRpYyB2b2lkCi1jb3VudF9yYW5nZXModV9sb25nIHN0YXJ0LCB1X2xv bmcgZW5kLCB2b2lkICphcmcpCitjb3VudF9yYW5nZXMoYnVzX2FkZHJfdCBzdGFydCwgYnVzX2Fk ZHJfdCBlbmQsIHZvaWQgKmFyZykKIHsKIAlpbnQgKmNvdW50cDsKIApAQCAtMzI0LDcgKzMyNSw3 IEBACiB9OwogCiBzdGF0aWMgdm9pZAotYWxsb2NfcmFuZ2VzKHVfbG9uZyBzdGFydCwgdV9sb25n IGVuZCwgdm9pZCAqYXJnKQorYWxsb2NfcmFuZ2VzKGJ1c19hZGRyX3Qgc3RhcnQsIGJ1c19hZGRy X3QgZW5kLCB2b2lkICphcmcpCiB7CiAJc3RydWN0IGFsbG9jX3N0YXRlICphczsKIAlzdHJ1Y3Qg cGNpYl93aW5kb3cgKnc7CkBAIC0zNDgsNyArMzQ5LDcgQEAKIH0KIAogc3RhdGljIGludAotcGNp Yl9hbGxvY19ub25pc2FfcmFuZ2VzKHN0cnVjdCBwY2liX3NvZnRjICpzYywgdV9sb25nIHN0YXJ0 LCB1X2xvbmcgZW5kKQorcGNpYl9hbGxvY19ub25pc2FfcmFuZ2VzKHN0cnVjdCBwY2liX3NvZnRj ICpzYywgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQpCiB7CiAJc3RydWN0IGFsbG9j X3N0YXRlIGFzOwogCWludCBpLCBuZXdfY291bnQ7CkBAIC0zODcsNyArMzg4LDcgQEAKIAljaGFy IGJ1Zls2NF07CiAJaW50IGVycm9yLCByaWQ7CiAKLQlpZiAobWF4X2FkZHJlc3MgIT0gKHVfbG9u ZyltYXhfYWRkcmVzcykKKwlpZiAobWF4X2FkZHJlc3MgIT0gKGJ1c19hZGRyX3QpbWF4X2FkZHJl c3MpCiAJCW1heF9hZGRyZXNzID0gfjB1bDsKIAl3LT5ybWFuLnJtX3N0YXJ0ID0gMDsKIAl3LT5y bWFuLnJtX2VuZCA9IG1heF9hZGRyZXNzOwpAQCAtNjA5LDcgKzYxMCw3IEBACiAKIHN0YXRpYyBz dHJ1Y3QgcmVzb3VyY2UgKgogcGNpYl9zdWJhbGxvY19idXMoc3RydWN0IHBjaWJfc2VjYnVzICpi dXMsIGRldmljZV90IGNoaWxkLCBpbnQgKnJpZCwKLSAgICB1X2xvbmcgc3RhcnQsIHVfbG9uZyBl bmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCisgICAgYnVzX2FkZHJfdCBzdGFydCwgYnVz X2FkZHJfdCBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCiB7CiAJc3RydWN0IHJlc291 cmNlICpyZXM7CiAKQEAgLTYzMyw5ICs2MzQsOSBAQAogICogc3ViYnVzLgogICovCiBzdGF0aWMg aW50Ci1wY2liX2dyb3dfc3ViYnVzKHN0cnVjdCBwY2liX3NlY2J1cyAqYnVzLCB1X2xvbmcgbmV3 X2VuZCkKK3BjaWJfZ3Jvd19zdWJidXMoc3RydWN0IHBjaWJfc2VjYnVzICpidXMsIGJ1c19hZGRy X3QgbmV3X2VuZCkKIHsKLQl1X2xvbmcgb2xkX2VuZDsKKwlidXNfYWRkcl90IG9sZF9lbmQ7CiAJ aW50IGVycm9yOwogCiAJb2xkX2VuZCA9IHJtYW5fZ2V0X2VuZChidXMtPnJlcyk7CkBAIC02NTgs MTAgKzY1OSwxMCBAQAogCiBzdHJ1Y3QgcmVzb3VyY2UgKgogcGNpYl9hbGxvY19zdWJidXMoc3Ry dWN0IHBjaWJfc2VjYnVzICpidXMsIGRldmljZV90IGNoaWxkLCBpbnQgKnJpZCwKLSAgICB1X2xv bmcgc3RhcnQsIHVfbG9uZyBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCisgICAgYnVz X2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3Mp CiB7CiAJc3RydWN0IHJlc291cmNlICpyZXM7Ci0JdV9sb25nIHN0YXJ0X2ZyZWUsIGVuZF9mcmVl LCBuZXdfZW5kOworCWJ1c19hZGRyX3Qgc3RhcnRfZnJlZSwgZW5kX2ZyZWUsIG5ld19lbmQ7CiAK IAkvKgogCSAqIEZpcnN0LCBzZWUgaWYgdGhlIHJlcXVlc3QgY2FuIGJlIHNhdGlzaWZpZWQgYnkg dGhlIGV4aXN0aW5nCkBAIC0xMTU4LDggKzExNTksOCBAQAogICovCiBzdGF0aWMgc3RydWN0IHJl c291cmNlICoKIHBjaWJfc3ViYWxsb2NfcmVzb3VyY2Uoc3RydWN0IHBjaWJfc29mdGMgKnNjLCBz dHJ1Y3QgcGNpYl93aW5kb3cgKncsCi0gICAgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQg KnJpZCwgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB1X2xvbmcgY291bnQsCi0gICAgdV9pbnQg ZmxhZ3MpCisgICAgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgKnJpZCwgYnVzX2FkZHJf dCBzdGFydCwgYnVzX2FkZHJfdCBlbmQsCisgICAgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykK IHsKIAlzdHJ1Y3QgcmVzb3VyY2UgKnJlczsKIApAQCAtMTE5NiwxMCArMTE5NywxMCBAQAogLyog QWxsb2NhdGUgYSBmcmVzaCByZXNvdXJjZSByYW5nZSBmb3IgYW4gdW5jb25maWd1cmVkIHdpbmRv dy4gKi8KIHN0YXRpYyBpbnQKIHBjaWJfYWxsb2NfbmV3X3dpbmRvdyhzdHJ1Y3QgcGNpYl9zb2Z0 YyAqc2MsIHN0cnVjdCBwY2liX3dpbmRvdyAqdywgaW50IHR5cGUsCi0gICAgdV9sb25nIHN0YXJ0 LCB1X2xvbmcgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKQorICAgIGJ1c19hZGRyX3Qg c3RhcnQsIGJ1c19hZGRyX3QgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKQogewogCXN0 cnVjdCByZXNvdXJjZSAqcmVzOwotCXVfbG9uZyBiYXNlLCBsaW1pdCwgd21hc2s7CisJYnVzX2Fk ZHJfdCBiYXNlLCBsaW1pdCwgd21hc2s7CiAJaW50IHJpZDsKIAogCS8qCkBAIC0xMjY5LDcgKzEy NzAsNyBAQAogLyogVHJ5IHRvIGV4cGFuZCBhbiBleGlzdGluZyB3aW5kb3cgdG8gdGhlIHJlcXVl c3RlZCBiYXNlIGFuZCBsaW1pdC4gKi8KIHN0YXRpYyBpbnQKIHBjaWJfZXhwYW5kX3dpbmRvdyhz dHJ1Y3QgcGNpYl9zb2Z0YyAqc2MsIHN0cnVjdCBwY2liX3dpbmRvdyAqdywgaW50IHR5cGUsCi0g ICAgdV9sb25nIGJhc2UsIHVfbG9uZyBsaW1pdCkKKyAgICBidXNfYWRkcl90IGJhc2UsIGJ1c19h ZGRyX3QgbGltaXQpCiB7CiAJc3RydWN0IHJlc291cmNlICpyZXM7CiAJaW50IGVycm9yLCBpLCBm b3JjZV82NGtfYmFzZTsKQEAgLTEzNjcsOSArMTM2OCwxMCBAQAogICovCiBzdGF0aWMgaW50CiBw Y2liX2dyb3dfd2luZG93KHN0cnVjdCBwY2liX3NvZnRjICpzYywgc3RydWN0IHBjaWJfd2luZG93 ICp3LCBpbnQgdHlwZSwKLSAgICB1X2xvbmcgc3RhcnQsIHVfbG9uZyBlbmQsIHVfbG9uZyBjb3Vu dCwgdV9pbnQgZmxhZ3MpCisgICAgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQsIHVf bG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCiB7Ci0JdV9sb25nIGFsaWduLCBzdGFydF9mcmVlLCBl bmRfZnJlZSwgZnJvbnQsIGJhY2ssIHdtYXNrOworCWJ1c19hZGRyX3Qgc3RhcnRfZnJlZSwgZW5k X2ZyZWUsIGZyb250LCBiYWNrOworCWJ1c19hZGRyX3QgYWxpZ24sIHdtYXNrOwogCWludCBlcnJv cjsKIAogCS8qCkBAIC0xNDAwLDggKzE0MDIsOCBAQAogCQlpZiAoZXJyb3IpIHsKIAkJCWlmIChi b290dmVyYm9zZSkKIAkJCQlkZXZpY2VfcHJpbnRmKHNjLT5kZXYsCi0JCSAgICAiZmFpbGVkIHRv IGFsbG9jYXRlIGluaXRpYWwgJXMgd2luZG93ICglI2x4LSUjbHgsJSNseClcbiIsCi0JCQkJICAg IHctPm5hbWUsIHN0YXJ0LCBlbmQsIGNvdW50KTsKKwkJICAgICJmYWlsZWQgdG8gYWxsb2NhdGUg aW5pdGlhbCAlcyB3aW5kb3cgKCUjangtJSNqeCwlI2x4KVxuIiwKKwkJCQkgICAgdy0+bmFtZSwg KHVpbnRtYXhfdClzdGFydCwgKHVpbnRtYXhfdCllbmQsIGNvdW50KTsKIAkJCXJldHVybiAoZXJy b3IpOwogCQl9CiAJCWlmIChib290dmVyYm9zZSkKQEAgLTE1MzQsNyArMTUzNiw3IEBACiAgKi8K IHN0cnVjdCByZXNvdXJjZSAqCiBwY2liX2FsbG9jX3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2 aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgKnJpZCwKLSAgICB1X2xvbmcgc3RhcnQsIHVfbG9u ZyBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCisgICAgYnVzX2FkZHJfdCBzdGFydCwg YnVzX2FkZHJfdCBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCiB7CiAJc3RydWN0IHBj aWJfc29mdGMgKnNjOwogCXN0cnVjdCByZXNvdXJjZSAqcjsKQEAgLTE2MjMsNyArMTYyNSw3IEBA CiAKIGludAogcGNpYl9hZGp1c3RfcmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGls ZCwgaW50IHR5cGUsIHN0cnVjdCByZXNvdXJjZSAqciwKLSAgICB1X2xvbmcgc3RhcnQsIHVfbG9u ZyBlbmQpCisgICAgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQpCiB7CiAJc3RydWN0 IHBjaWJfc29mdGMgKnNjOwogCkBAIC0xNjU4LDcgKzE2NjAsNyBAQAogICovCiBzdHJ1Y3QgcmVz b3VyY2UgKgogcGNpYl9hbGxvY19yZXNvdXJjZShkZXZpY2VfdCBkZXYsIGRldmljZV90IGNoaWxk LCBpbnQgdHlwZSwgaW50ICpyaWQsIAotICAgIHVfbG9uZyBzdGFydCwgdV9sb25nIGVuZCwgdV9s b25nIGNvdW50LCB1X2ludCBmbGFncykKKyAgICBidXNfYWRkcl90IHN0YXJ0LCBidXNfYWRkcl90 IGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKIHsKIAlzdHJ1Y3QgcGNpYl9zb2Z0Ywkq c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CiAJY29uc3QgY2hhciAqbmFtZSwgKnN1ZmZpeDsK SW5kZXg6IHN5cy9kZXYvcGNpL3BjaV9wcml2YXRlLmgKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9w Y2kvcGNpX3ByaXZhdGUuaAkocmV2aXNpb24gMjg3MTg5KQorKysgc3lzL2Rldi9wY2kvcGNpX3By aXZhdGUuaAkod29ya2luZyBjb3B5KQpAQCAtMTAzLDggKzEwMyw4IEBACiBpbnQJCXBjaV9tc2lf Y291bnRfbWV0aG9kKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQpOwogaW50CQlwY2lfbXNp eF9jb3VudF9tZXRob2QoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCk7CiBzdHJ1Y3QgcmVz b3VyY2UJKnBjaV9hbGxvY19yZXNvdXJjZShkZXZpY2VfdCBkZXYsIGRldmljZV90IGNoaWxkLCAK LQkJICAgIGludCB0eXBlLCBpbnQgKnJpZCwgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB1X2xv bmcgY291bnQsCi0JCSAgICB1X2ludCBmbGFncyk7CisJCSAgICBpbnQgdHlwZSwgaW50ICpyaWQs IGJ1c19hZGRyX3Qgc3RhcnQsIGJ1c19hZGRyX3QgZW5kLAorCQkgICAgdV9sb25nIGNvdW50LCB1 X2ludCBmbGFncyk7CiBpbnQJCXBjaV9yZWxlYXNlX3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2 aWNlX3QgY2hpbGQsIGludCB0eXBlLAogCQkgICAgaW50IHJpZCwgc3RydWN0IHJlc291cmNlICpy KTsKIGludAkJcGNpX2FjdGl2YXRlX3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hp bGQsIGludCB0eXBlLApJbmRleDogc3lzL2Rldi9wY2kvcGNpX3N1YnIuYwo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBzeXMvZGV2L3BjaS9wY2lfc3Vici5jCShyZXZpc2lvbiAyODcxODkpCisrKyBzeXMvZGV2L3Bj aS9wY2lfc3Vici5jCSh3b3JraW5nIGNvcHkpCkBAIC0xNzgsOCArMTc4LDggQEAKIH0KIAogaW50 Ci1wY2liX2hvc3RfcmVzX2RlY29kZXMoc3RydWN0IHBjaWJfaG9zdF9yZXNvdXJjZXMgKmhyLCBp bnQgdHlwZSwgdV9sb25nIHN0YXJ0LAotICAgIHVfbG9uZyBlbmQsIHVfaW50IGZsYWdzKQorcGNp Yl9ob3N0X3Jlc19kZWNvZGVzKHN0cnVjdCBwY2liX2hvc3RfcmVzb3VyY2VzICpociwgaW50IHR5 cGUsIGJ1c19hZGRyX3Qgc3RhcnQsCisgICAgYnVzX2FkZHJfdCBlbmQsIHVfaW50IGZsYWdzKQog ewogCXN0cnVjdCByZXNvdXJjZV9saXN0X2VudHJ5ICpybGU7CiAJaW50IHJpZDsKQEAgLTIwMSwx MSArMjAxLDExIEBACiAKIHN0cnVjdCByZXNvdXJjZSAqCiBwY2liX2hvc3RfcmVzX2FsbG9jKHN0 cnVjdCBwY2liX2hvc3RfcmVzb3VyY2VzICpociwgZGV2aWNlX3QgZGV2LCBpbnQgdHlwZSwKLSAg ICBpbnQgKnJpZCwgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50 IGZsYWdzKQorICAgIGludCAqcmlkLCBidXNfYWRkcl90IHN0YXJ0LCBidXNfYWRkcl90IGVuZCwg dV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKIHsKIAlzdHJ1Y3QgcmVzb3VyY2VfbGlzdF9lbnRy eSAqcmxlOwogCXN0cnVjdCByZXNvdXJjZSAqcjsKLQl1X2xvbmcgbmV3X3N0YXJ0LCBuZXdfZW5k OworCWJ1c19hZGRyX3QgbmV3X3N0YXJ0LCBuZXdfZW5kOwogCiAJaWYgKGZsYWdzICYgUkZfUFJF RkVUQ0hBQkxFKQogCQlLQVNTRVJUKHR5cGUgPT0gU1lTX1JFU19NRU1PUlksCkBAIC0yMjksOCAr MjI5LDggQEAKIAkJaWYgKCgoZmxhZ3MgJiBSRl9QUkVGRVRDSEFCTEUpICE9IDApICE9CiAJCSAg ICAoKHJsZS0+ZmxhZ3MgJiBSTEVfUFJFRkVUQ0gpICE9IDApKQogCQkJY29udGludWU7Ci0JCW5l d19zdGFydCA9IHVsbWF4KHN0YXJ0LCBybGUtPnN0YXJ0KTsKLQkJbmV3X2VuZCA9IHVsbWluKGVu ZCwgcmxlLT5lbmQpOworCQluZXdfc3RhcnQgPSBxbWF4KHN0YXJ0LCBybGUtPnN0YXJ0KTsKKwkJ bmV3X2VuZCA9IHFtaW4oZW5kLCBybGUtPmVuZCk7CiAJCWlmIChuZXdfc3RhcnQgPiBuZXdfZW5k IHx8CiAJCSAgICBuZXdfc3RhcnQgKyBjb3VudCAtIDEgPiBuZXdfZW5kIHx8CiAJCSAgICBuZXdf c3RhcnQgKyBjb3VudCA8IG5ld19zdGFydCkKQEAgLTI2MSw3ICsyNjEsNyBAQAogCiBpbnQKIHBj aWJfaG9zdF9yZXNfYWRqdXN0KHN0cnVjdCBwY2liX2hvc3RfcmVzb3VyY2VzICpociwgZGV2aWNl X3QgZGV2LCBpbnQgdHlwZSwKLSAgICBzdHJ1Y3QgcmVzb3VyY2UgKnIsIHVfbG9uZyBzdGFydCwg dV9sb25nIGVuZCkKKyAgICBzdHJ1Y3QgcmVzb3VyY2UgKnIsIGJ1c19hZGRyX3Qgc3RhcnQsIGJ1 c19hZGRyX3QgZW5kKQogewogCXN0cnVjdCByZXNvdXJjZV9saXN0X2VudHJ5ICpybGU7CiAKQEAg LTMyOSw4ICszMjksOCBAQAogfQogCiBzdHJ1Y3QgcmVzb3VyY2UgKgotcGNpX2RvbWFpbl9hbGxv Y19idXMoaW50IGRvbWFpbiwgZGV2aWNlX3QgZGV2LCBpbnQgKnJpZCwgdV9sb25nIHN0YXJ0LAot ICAgIHVfbG9uZyBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCitwY2lfZG9tYWluX2Fs bG9jX2J1cyhpbnQgZG9tYWluLCBkZXZpY2VfdCBkZXYsIGludCAqcmlkLCBidXNfYWRkcl90IHN0 YXJ0LAorICAgIGJ1c19hZGRyX3QgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKQogewog CXN0cnVjdCBwY2lfZG9tYWluICpkOwogCXN0cnVjdCByZXNvdXJjZSAqcmVzOwpAQCAtMzQ5LDcg KzM0OSw3IEBACiAKIGludAogcGNpX2RvbWFpbl9hZGp1c3RfYnVzKGludCBkb21haW4sIGRldmlj ZV90IGRldiwgc3RydWN0IHJlc291cmNlICpyLAotICAgIHVfbG9uZyBzdGFydCwgdV9sb25nIGVu ZCkKKyAgICBidXNfYWRkcl90IHN0YXJ0LCBidXNfYWRkcl90IGVuZCkKIHsKICNpZmRlZiBJTlZB UklBTlRTCiAJc3RydWN0IHBjaV9kb21haW4gKmQ7CkluZGV4OiBzeXMvZGV2L3BjaS9wY2liX3By aXZhdGUuaAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvZGV2L3BjaS9wY2liX3ByaXZhdGUuaAkocmV2aXNp b24gMjg3MTg5KQorKysgc3lzL2Rldi9wY2kvcGNpYl9wcml2YXRlLmgJKHdvcmtpbmcgY29weSkK QEAgLTQ5LDEzICs0OSwxMyBAQAogaW50CQlwY2liX2hvc3RfcmVzX2ZyZWUoZGV2aWNlX3QgcGNp YiwKIAkJICAgIHN0cnVjdCBwY2liX2hvc3RfcmVzb3VyY2VzICpocik7CiBpbnQJCXBjaWJfaG9z dF9yZXNfZGVjb2RlcyhzdHJ1Y3QgcGNpYl9ob3N0X3Jlc291cmNlcyAqaHIsIGludCB0eXBlLAot CQkgICAgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB1X2ludCBmbGFncyk7CisJCSAgICBidXNf YWRkcl90IHN0YXJ0LCBidXNfYWRkcl90IGVuZCwgdV9pbnQgZmxhZ3MpOwogc3RydWN0IHJlc291 cmNlICpwY2liX2hvc3RfcmVzX2FsbG9jKHN0cnVjdCBwY2liX2hvc3RfcmVzb3VyY2VzICpociwK LQkJICAgIGRldmljZV90IGRldiwgaW50IHR5cGUsIGludCAqcmlkLCB1X2xvbmcgc3RhcnQsIHVf bG9uZyBlbmQsCi0JCSAgICB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKTsKKwkJICAgIGRldmlj ZV90IGRldiwgaW50IHR5cGUsIGludCAqcmlkLCBidXNfYWRkcl90IHN0YXJ0LAorCQkgICAgYnVz X2FkZHJfdCBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpOwogaW50CQlwY2liX2hvc3Rf cmVzX2FkanVzdChzdHJ1Y3QgcGNpYl9ob3N0X3Jlc291cmNlcyAqaHIsCi0JCSAgICBkZXZpY2Vf dCBkZXYsIGludCB0eXBlLCBzdHJ1Y3QgcmVzb3VyY2UgKnIsIHVfbG9uZyBzdGFydCwKLQkJICAg IHVfbG9uZyBlbmQpOworCQkgICAgZGV2aWNlX3QgZGV2LCBpbnQgdHlwZSwgc3RydWN0IHJlc291 cmNlICpyLCBidXNfYWRkcl90IHN0YXJ0LAorCQkgICAgYnVzX2FkZHJfdCBlbmQpOwogI2VuZGlm CiAKIC8qCkBAIC0xMzIsMTMgKzEzMiwxMyBAQAogICAgIGludCBzbG90LCBpbnQgZnVuYywgdWlu dDhfdCAqYnVzbnVtKTsKICNpZiBkZWZpbmVkKE5FV19QQ0lCKSAmJiBkZWZpbmVkKFBDSV9SRVNf QlVTKQogc3RydWN0IHJlc291cmNlICpwY2lfZG9tYWluX2FsbG9jX2J1cyhpbnQgZG9tYWluLCBk ZXZpY2VfdCBkZXYsIGludCAqcmlkLAotCQkgICAgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB1 X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKTsKKwkJICAgIGJ1c19hZGRyX3Qgc3RhcnQsIGJ1c19h ZGRyX3QgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKTsKIGludAkJcGNpX2RvbWFpbl9h ZGp1c3RfYnVzKGludCBkb21haW4sIGRldmljZV90IGRldiwKLQkJICAgIHN0cnVjdCByZXNvdXJj ZSAqciwgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kKTsKKwkJICAgIHN0cnVjdCByZXNvdXJjZSAq ciwgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQpOwogaW50CQlwY2lfZG9tYWluX3Jl bGVhc2VfYnVzKGludCBkb21haW4sIGRldmljZV90IGRldiwgaW50IHJpZCwKIAkJICAgIHN0cnVj dCByZXNvdXJjZSAqcik7CiBzdHJ1Y3QgcmVzb3VyY2UgKnBjaWJfYWxsb2Nfc3ViYnVzKHN0cnVj dCBwY2liX3NlY2J1cyAqYnVzLCBkZXZpY2VfdCBjaGlsZCwKLQkJICAgIGludCAqcmlkLCB1X2xv bmcgc3RhcnQsIHVfbG9uZyBlbmQsIHVfbG9uZyBjb3VudCwKKwkJICAgIGludCAqcmlkLCBidXNf YWRkcl90IHN0YXJ0LCBidXNfYWRkcl90IGVuZCwgdV9sb25nIGNvdW50LAogCQkgICAgdV9pbnQg ZmxhZ3MpOwogdm9pZAkJcGNpYl9zZXR1cF9zZWNidXMoZGV2aWNlX3QgZGV2LCBzdHJ1Y3QgcGNp Yl9zZWNidXMgKmJ1cywKICAgICBpbnQgbWluX2NvdW50KTsKQEAgLTE1MiwxMCArMTUyLDExIEBA CiBpbnQJCXBjaWJfcmVhZF9pdmFyKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB3 aGljaCwgdWludHB0cl90ICpyZXN1bHQpOwogaW50CQlwY2liX3dyaXRlX2l2YXIoZGV2aWNlX3Qg ZGV2LCBkZXZpY2VfdCBjaGlsZCwgaW50IHdoaWNoLCB1aW50cHRyX3QgdmFsdWUpOwogc3RydWN0 IHJlc291cmNlICpwY2liX2FsbG9jX3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hp bGQsIGludCB0eXBlLCBpbnQgKnJpZCwgCi0JCQkJCSAgICB1X2xvbmcgc3RhcnQsIHVfbG9uZyBl bmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpOworCQkJCQkgICAgYnVzX2FkZHJfdCBzdGFy dCwgYnVzX2FkZHJfdCBlbmQsCisJCQkJCSAgICB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKTsK ICNpZmRlZiBORVdfUENJQgogaW50CQlwY2liX2FkanVzdF9yZXNvdXJjZShkZXZpY2VfdCBidXMs IGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwKLSAgICBzdHJ1Y3QgcmVzb3VyY2UgKnIsIHVfbG9u ZyBzdGFydCwgdV9sb25nIGVuZCk7CisgICAgc3RydWN0IHJlc291cmNlICpyLCBidXNfYWRkcl90 IHN0YXJ0LCBidXNfYWRkcl90IGVuZCk7CiBpbnQJCXBjaWJfcmVsZWFzZV9yZXNvdXJjZShkZXZp Y2VfdCBkZXYsIGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50IHJpZCwKICAgICBzdHJ1Y3Qg cmVzb3VyY2UgKnIpOwogI2VuZGlmCkluZGV4OiBzeXMvZGV2L3BjaS92Z2FfcGNpLmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL2Rldi9wY2kvdmdhX3BjaS5jCShyZXZpc2lvbiAyODcxODkpCisrKyBzeXMv ZGV2L3BjaS92Z2FfcGNpLmMJKHdvcmtpbmcgY29weSkKQEAgLTY4LDcgKzY4LDcgQEAKIAogc3Rh dGljIHN0cnVjdCB2Z2FfcmVzb3VyY2UgKmxvb2t1cF9yZXMoc3RydWN0IHZnYV9wY2lfc29mdGMg KnNjLCBpbnQgcmlkKTsKIHN0YXRpYyBzdHJ1Y3QgcmVzb3VyY2UgKnZnYV9wY2lfYWxsb2NfcmVz b3VyY2UoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwKLSAgICBpbnQgdHlwZSwgaW50ICpy aWQsIHVfbG9uZyBzdGFydCwgdV9sb25nIGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncyk7 CisgICAgaW50IHR5cGUsIGludCAqcmlkLCBidXNfYWRkcl90IHN0YXJ0LCBidXNfYWRkcl90IGVu ZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncyk7CiBzdGF0aWMgaW50CXZnYV9wY2lfcmVsZWFz ZV9yZXNvdXJjZShkZXZpY2VfdCBkZXYsIGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwKICAgICBp bnQgcmlkLCBzdHJ1Y3QgcmVzb3VyY2UgKnIpOwogCkBAIC0xNjMsOCArMTYzLDggQEAKICNlbmRp ZgogCiAJcmlkID0gUENJUl9CSU9TOwotCXJlcyA9IHZnYV9wY2lfYWxsb2NfcmVzb3VyY2UoZGV2 LCBOVUxMLCBTWVNfUkVTX01FTU9SWSwgJnJpZCwgMHVsLAotCSAgICB+MHVsLCAxLCBSRl9BQ1RJ VkUpOworCXJlcyA9IHZnYV9wY2lfYWxsb2NfcmVzb3VyY2UoZGV2LCBOVUxMLCBTWVNfUkVTX01F TU9SWSwgJnJpZCwgUk1fTUlOX1NUQVJULAorCSAgICBSTV9NQVhfRU5ELCAxLCBSRl9BQ1RJVkUp OwogCWlmIChyZXMgPT0gTlVMTCkgewogCQlyZXR1cm4gKE5VTEwpOwogCX0KQEAgLTMzMyw3ICsz MzMsNyBAQAogCiBzdGF0aWMgc3RydWN0IHJlc291cmNlICoKIHZnYV9wY2lfYWxsb2NfcmVzb3Vy Y2UoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlkLAotICAg IHVfbG9uZyBzdGFydCwgdV9sb25nIGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKKyAg ICBidXNfYWRkcl90IHN0YXJ0LCBidXNfYWRkcl90IGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBm bGFncykKIHsKIAlzdHJ1Y3QgdmdhX3Jlc291cmNlICp2cjsKIApJbmRleDogc3lzL2Rldi9zY2Mv c2NjX2JmZS5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvc2NjL3NjY19iZmUuaAkocmV2aXNpb24g Mjg3MTg5KQorKysgc3lzL2Rldi9zY2Mvc2NjX2JmZS5oCSh3b3JraW5nIGNvcHkpCkBAIC0xNDMs OCArMTQzLDggQEAKIGludCBzY2NfYmZlX3Byb2JlKGRldmljZV90IGRldiwgdV9pbnQgcmVnc2hm dCwgdV9pbnQgcmNsaywgdV9pbnQgcmlkKTsKIAogc3RydWN0IHJlc291cmNlICpzY2NfYnVzX2Fs bG9jX3Jlc291cmNlKGRldmljZV90LCBkZXZpY2VfdCwgaW50LCBpbnQgKiwKLSAgICB1X2xvbmcs IHVfbG9uZywgdV9sb25nLCB1X2ludCk7Ci1pbnQgc2NjX2J1c19nZXRfcmVzb3VyY2UoZGV2aWNl X3QsIGRldmljZV90LCBpbnQsIGludCwgdV9sb25nICosIHVfbG9uZyAqKTsKKyAgICBidXNfYWRk cl90LCBidXNfYWRkcl90LCB1X2xvbmcsIHVfaW50KTsKK2ludCBzY2NfYnVzX2dldF9yZXNvdXJj ZShkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwgaW50LCBidXNfYWRkcl90ICosIHVfbG9uZyAqKTsK IGludCBzY2NfYnVzX3JlYWRfaXZhcihkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwgdWludHB0cl90 ICopOwogaW50IHNjY19idXNfcmVsZWFzZV9yZXNvdXJjZShkZXZpY2VfdCwgZGV2aWNlX3QsIGlu dCwgaW50LCBzdHJ1Y3QgcmVzb3VyY2UgKik7CiBpbnQgc2NjX2J1c19zZXR1cF9pbnRyKGRldmlj ZV90LCBkZXZpY2VfdCwgc3RydWN0IHJlc291cmNlICosIGludCwKSW5kZXg6IHN5cy9kZXYvc2Nj L3NjY19jb3JlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi9zY2Mvc2NjX2NvcmUuYwkocmV2aXNp b24gMjg3MTg5KQorKysgc3lzL2Rldi9zY2Mvc2NjX2NvcmUuYwkod29ya2luZyBjb3B5KQpAQCAt MTAzLDcgKzEwMyw4IEBACiAJc3RydWN0IHNjY19zb2Z0YyAqc2MsICpzYzA7CiAJY29uc3QgY2hh ciAqc2VwOwogCWJ1c19zcGFjZV9oYW5kbGVfdCBiaDsKLQl1X2xvbmcgYmFzZSwgc2l6ZSwgc3Rh cnQsIHN6OworCWJ1c19hZGRyX3QgYmFzZSwgc3RhcnQ7CisJYnVzX3NpemVfdCBzaXplLCBzejsK IAlpbnQgYywgZXJyb3IsIG1vZGUsIHN5c2RldjsKIAogCS8qCkBAIC00MDcsNyArNDA4LDcgQEAK IAogc3RydWN0IHJlc291cmNlICoKIHNjY19idXNfYWxsb2NfcmVzb3VyY2UoZGV2aWNlX3QgZGV2 LCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlkLAotICAgIHVfbG9uZyBzdGFydCwg dV9sb25nIGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKKyAgICBidXNfYWRkcl90IHN0 YXJ0LCBidXNfYWRkcl90IGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKIHsKIAlzdHJ1 Y3QgcmVzb3VyY2VfbGlzdF9lbnRyeSAqcmxlOwogCXN0cnVjdCBzY2NfY2hhbiAqY2g7CkBAIC00 MzEsNyArNDMyLDcgQEAKIAogaW50CiBzY2NfYnVzX2dldF9yZXNvdXJjZShkZXZpY2VfdCBkZXYs IGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50IHJpZCwKLSAgICB1X2xvbmcgKnN0YXJ0cCwg dV9sb25nICpjb3VudHApCisgICAgYnVzX2FkZHJfdCAqc3RhcnRwLCB1X2xvbmcgKmNvdW50cCkK IHsKIAlzdHJ1Y3QgcmVzb3VyY2VfbGlzdF9lbnRyeSAqcmxlOwogCXN0cnVjdCBzY2NfY2hhbiAq Y2g7CkluZGV4OiBzeXMva2Vybi9idXNfaWYubQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMva2Vybi9idXNf aWYubQkocmV2aXNpb24gMjg3MTg5KQorKysgc3lzL2tlcm4vYnVzX2lmLm0JKHdvcmtpbmcgY29w eSkKQEAgLTQ0LDcgKzQ0LDcgQEAKIENPREUgewogCXN0YXRpYyBzdHJ1Y3QgcmVzb3VyY2UgKgog CW51bGxfYWxsb2NfcmVzb3VyY2UoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwKLQkgICAg aW50IHR5cGUsIGludCAqcmlkLCB1X2xvbmcgc3RhcnQsIHVfbG9uZyBlbmQsCisJICAgIGludCB0 eXBlLCBpbnQgKnJpZCwgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQsCiAJICAgIHVf bG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCiAJewogCSAgICByZXR1cm4gKDApOwpAQCAtMjYyLDgg KzI2Miw4IEBACiAJZGV2aWNlX3QJX2NoaWxkOwogCWludAkJX3R5cGU7CiAJaW50CSAgICAgICAq X3JpZDsKLQl1X2xvbmcJCV9zdGFydDsKLQl1X2xvbmcJCV9lbmQ7CisJYnVzX2FkZHJfdAlfc3Rh cnQ7CisJYnVzX2FkZHJfdAlfZW5kOwogCXVfbG9uZwkJX2NvdW50OwogCXVfaW50CQlfZmxhZ3M7 CiB9IERFRkFVTFQgbnVsbF9hbGxvY19yZXNvdXJjZTsKQEAgLTMzMCw4ICszMzAsOCBAQAogCWRl dmljZV90CV9jaGlsZDsKIAlpbnQJCV90eXBlOwogCXN0cnVjdCByZXNvdXJjZSAqX3JlczsKLQl1 X2xvbmcJCV9zdGFydDsKLQl1X2xvbmcJCV9lbmQ7CisJYnVzX2FkZHJfdAlfc3RhcnQ7CisJYnVz X2FkZHJfdAlfZW5kOwogfTsKIAogLyoqCkBAIC00MzEsNyArNDMxLDcgQEAKIAlkZXZpY2VfdAlf Y2hpbGQ7CiAJaW50CQlfdHlwZTsKIAlpbnQJCV9yaWQ7Ci0JdV9sb25nCQlfc3RhcnQ7CisJYnVz X2FkZHJfdAlfc3RhcnQ7CiAJdV9sb25nCQlfY291bnQ7CiB9OwogCkBAIC00NTUsNyArNDU1LDcg QEAKIAlkZXZpY2VfdAlfY2hpbGQ7CiAJaW50CQlfdHlwZTsKIAlpbnQJCV9yaWQ7Ci0JdV9sb25n CQkqX3N0YXJ0cDsKKwlidXNfYWRkcl90CSpfc3RhcnRwOwogCXVfbG9uZwkJKl9jb3VudHA7CiB9 OwogCkluZGV4OiBzeXMva2Vybi9zdWJyX2J1cy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuL3N1 YnJfYnVzLmMJKHJldmlzaW9uIDI4NzE4OSkKKysrIHN5cy9rZXJuL3N1YnJfYnVzLmMJKHdvcmtp bmcgY29weSkKQEAgLTMwNjMsOCArMzA2Myw4IEBACiAgKiBAcGFyYW0gY291bnQJCVhYWCBlbmQt c3RhcnQrMQogICovCiBpbnQKLXJlc291cmNlX2xpc3RfYWRkX25leHQoc3RydWN0IHJlc291cmNl X2xpc3QgKnJsLCBpbnQgdHlwZSwgdV9sb25nIHN0YXJ0LAotICAgIHVfbG9uZyBlbmQsIHVfbG9u ZyBjb3VudCkKK3Jlc291cmNlX2xpc3RfYWRkX25leHQoc3RydWN0IHJlc291cmNlX2xpc3QgKnJs LCBpbnQgdHlwZSwgYnVzX2FkZHJfdCBzdGFydCwKKyAgICBidXNfYWRkcl90IGVuZCwgdV9sb25n IGNvdW50KQogewogCWludCByaWQ7CiAKQEAgLTMwOTIsNyArMzA5Miw3IEBACiAgKi8KIHN0cnVj dCByZXNvdXJjZV9saXN0X2VudHJ5ICoKIHJlc291cmNlX2xpc3RfYWRkKHN0cnVjdCByZXNvdXJj ZV9saXN0ICpybCwgaW50IHR5cGUsIGludCByaWQsCi0gICAgdV9sb25nIHN0YXJ0LCB1X2xvbmcg ZW5kLCB1X2xvbmcgY291bnQpCisgICAgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQs IHVfbG9uZyBjb3VudCkKIHsKIAlzdHJ1Y3QgcmVzb3VyY2VfbGlzdF9lbnRyeSAqcmxlOwogCkBA IC0zMjUwLDcgKzMyNTAsNyBAQAogICovCiBzdHJ1Y3QgcmVzb3VyY2UgKgogcmVzb3VyY2VfbGlz dF9yZXNlcnZlKHN0cnVjdCByZXNvdXJjZV9saXN0ICpybCwgZGV2aWNlX3QgYnVzLCBkZXZpY2Vf dCBjaGlsZCwKLSAgICBpbnQgdHlwZSwgaW50ICpyaWQsIHVfbG9uZyBzdGFydCwgdV9sb25nIGVu ZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKKyAgICBpbnQgdHlwZSwgaW50ICpyaWQsIGJ1 c19hZGRyX3Qgc3RhcnQsIGJ1c19hZGRyX3QgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdz KQogewogCXN0cnVjdCByZXNvdXJjZV9saXN0X2VudHJ5ICpybGUgPSBOVUxMOwogCWludCBwYXNz dGhyb3VnaCA9IChkZXZpY2VfZ2V0X3BhcmVudChjaGlsZCkgIT0gYnVzKTsKQEAgLTMzMDcsNyAr MzMwNyw3IEBACiAgKi8KIHN0cnVjdCByZXNvdXJjZSAqCiByZXNvdXJjZV9saXN0X2FsbG9jKHN0 cnVjdCByZXNvdXJjZV9saXN0ICpybCwgZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwKLSAg ICBpbnQgdHlwZSwgaW50ICpyaWQsIHVfbG9uZyBzdGFydCwgdV9sb25nIGVuZCwgdV9sb25nIGNv dW50LCB1X2ludCBmbGFncykKKyAgICBpbnQgdHlwZSwgaW50ICpyaWQsIGJ1c19hZGRyX3Qgc3Rh cnQsIGJ1c19hZGRyX3QgZW5kLCB1X2xvbmcgY291bnQsIHVfaW50IGZsYWdzKQogewogCXN0cnVj dCByZXNvdXJjZV9saXN0X2VudHJ5ICpybGUgPSBOVUxMOwogCWludCBwYXNzdGhyb3VnaCA9IChk ZXZpY2VfZ2V0X3BhcmVudChjaGlsZCkgIT0gYnVzKTsKQEAgLTM5NDksNyArMzk0OSw3IEBACiAg Ki8KIGludAogYnVzX2dlbmVyaWNfYWRqdXN0X3Jlc291cmNlKGRldmljZV90IGRldiwgZGV2aWNl X3QgY2hpbGQsIGludCB0eXBlLAotICAgIHN0cnVjdCByZXNvdXJjZSAqciwgdV9sb25nIHN0YXJ0 LCB1X2xvbmcgZW5kKQorICAgIHN0cnVjdCByZXNvdXJjZSAqciwgYnVzX2FkZHJfdCBzdGFydCwg YnVzX2FkZHJfdCBlbmQpCiB7CiAJLyogUHJvcGFnYXRlIHVwIHRoZSBidXMgaGllcmFyY2h5IHVu dGlsIHNvbWVvbmUgaGFuZGxlcyBpdC4gKi8KIAlpZiAoZGV2LT5wYXJlbnQpCkBAIC0zOTY2LDcg KzM5NjYsNyBAQAogICovCiBzdHJ1Y3QgcmVzb3VyY2UgKgogYnVzX2dlbmVyaWNfYWxsb2NfcmVz b3VyY2UoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlkLAot ICAgIHVfbG9uZyBzdGFydCwgdV9sb25nIGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykK KyAgICBidXNfYWRkcl90IHN0YXJ0LCBidXNfYWRkcl90IGVuZCwgdV9sb25nIGNvdW50LCB1X2lu dCBmbGFncykKIHsKIAkvKiBQcm9wYWdhdGUgdXAgdGhlIGJ1cyBoaWVyYXJjaHkgdW50aWwgc29t ZW9uZSBoYW5kbGVzIGl0LiAqLwogCWlmIChkZXYtPnBhcmVudCkKQEAgLTQxMDQsNyArNDEwNCw3 IEBACiAgKi8KIGludAogYnVzX2dlbmVyaWNfcmxfZ2V0X3Jlc291cmNlKGRldmljZV90IGRldiwg ZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlkLAotICAgIHVfbG9uZyAqc3RhcnRwLCB1 X2xvbmcgKmNvdW50cCkKKyAgICBidXNfYWRkcl90ICpzdGFydHAsIHVfbG9uZyAqY291bnRwKQog ewogCXN0cnVjdCByZXNvdXJjZV9saXN0ICoJCXJsID0gTlVMTDsKIAlzdHJ1Y3QgcmVzb3VyY2Vf bGlzdF9lbnRyeSAqCXJsZSA9IE5VTEw7CkBAIC00MTM1LDcgKzQxMzUsNyBAQAogICovCiBpbnQK IGJ1c19nZW5lcmljX3JsX3NldF9yZXNvdXJjZShkZXZpY2VfdCBkZXYsIGRldmljZV90IGNoaWxk LCBpbnQgdHlwZSwgaW50IHJpZCwKLSAgICB1X2xvbmcgc3RhcnQsIHVfbG9uZyBjb3VudCkKKyAg ICBidXNfYWRkcl90IHN0YXJ0LCB1X2xvbmcgY291bnQpCiB7CiAJc3RydWN0IHJlc291cmNlX2xp c3QgKgkJcmwgPSBOVUxMOwogCkBAIC00MjAzLDcgKzQyMDMsNyBAQAogICovCiBzdHJ1Y3QgcmVz b3VyY2UgKgogYnVzX2dlbmVyaWNfcmxfYWxsb2NfcmVzb3VyY2UoZGV2aWNlX3QgZGV2LCBkZXZp Y2VfdCBjaGlsZCwgaW50IHR5cGUsCi0gICAgaW50ICpyaWQsIHVfbG9uZyBzdGFydCwgdV9sb25n IGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKKyAgICBpbnQgKnJpZCwgYnVzX2FkZHJf dCBzdGFydCwgYnVzX2FkZHJfdCBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCiB7CiAJ c3RydWN0IHJlc291cmNlX2xpc3QgKgkJcmwgPSBOVUxMOwogCkBAIC00Mjg5LDcgKzQyODksNyBA QAogICogcGFyZW50IG9mIEBwIGRldi4KICAqLwogc3RydWN0IHJlc291cmNlICoKLWJ1c19hbGxv Y19yZXNvdXJjZShkZXZpY2VfdCBkZXYsIGludCB0eXBlLCBpbnQgKnJpZCwgdV9sb25nIHN0YXJ0 LCB1X2xvbmcgZW5kLAorYnVzX2FsbG9jX3Jlc291cmNlKGRldmljZV90IGRldiwgaW50IHR5cGUs IGludCAqcmlkLCBidXNfYWRkcl90IHN0YXJ0LCBidXNfYWRkcl90IGVuZCwKICAgICB1X2xvbmcg Y291bnQsIHVfaW50IGZsYWdzKQogewogCWlmIChkZXYtPnBhcmVudCA9PSBOVUxMKQpAQCAtNDMw NSw4ICs0MzA1LDggQEAKICAqIHBhcmVudCBvZiBAcCBkZXYuCiAgKi8KIGludAotYnVzX2FkanVz dF9yZXNvdXJjZShkZXZpY2VfdCBkZXYsIGludCB0eXBlLCBzdHJ1Y3QgcmVzb3VyY2UgKnIsIHVf bG9uZyBzdGFydCwKLSAgICB1X2xvbmcgZW5kKQorYnVzX2FkanVzdF9yZXNvdXJjZShkZXZpY2Vf dCBkZXYsIGludCB0eXBlLCBzdHJ1Y3QgcmVzb3VyY2UgKnIsIGJ1c19hZGRyX3Qgc3RhcnQsCisg ICAgYnVzX2FkZHJfdCBlbmQpCiB7CiAJaWYgKGRldi0+cGFyZW50ID09IE5VTEwpCiAJCXJldHVy biAoRUlOVkFMKTsKQEAgLTQ0MzYsNyArNDQzNiw3IEBACiAgKi8KIGludAogYnVzX3NldF9yZXNv dXJjZShkZXZpY2VfdCBkZXYsIGludCB0eXBlLCBpbnQgcmlkLAotICAgIHVfbG9uZyBzdGFydCwg dV9sb25nIGNvdW50KQorICAgIGJ1c19hZGRyX3Qgc3RhcnQsIHVfbG9uZyBjb3VudCkKIHsKIAly ZXR1cm4gKEJVU19TRVRfUkVTT1VSQ0UoZGV2aWNlX2dldF9wYXJlbnQoZGV2KSwgZGV2LCB0eXBl LCByaWQsCiAJICAgIHN0YXJ0LCBjb3VudCkpOwpAQCAtNDQ1MCw3ICs0NDUwLDcgQEAKICAqLwog aW50CiBidXNfZ2V0X3Jlc291cmNlKGRldmljZV90IGRldiwgaW50IHR5cGUsIGludCByaWQsCi0g ICAgdV9sb25nICpzdGFydHAsIHVfbG9uZyAqY291bnRwKQorICAgIGJ1c19hZGRyX3QgKnN0YXJ0 cCwgdV9sb25nICpjb3VudHApCiB7CiAJcmV0dXJuIChCVVNfR0VUX1JFU09VUkNFKGRldmljZV9n ZXRfcGFyZW50KGRldiksIGRldiwgdHlwZSwgcmlkLAogCSAgICBzdGFydHAsIGNvdW50cCkpOwpA QCAtNDQ2MiwxMCArNDQ2MiwxMSBAQAogICogVGhpcyBmdW5jdGlvbiBzaW1wbHkgY2FsbHMgdGhl IEJVU19HRVRfUkVTT1VSQ0UoKSBtZXRob2Qgb2YgdGhlCiAgKiBwYXJlbnQgb2YgQHAgZGV2IGFu ZCByZXR1cm5zIHRoZSBzdGFydCB2YWx1ZS4KICAqLwotdV9sb25nCitidXNfYWRkcl90CiBidXNf Z2V0X3Jlc291cmNlX3N0YXJ0KGRldmljZV90IGRldiwgaW50IHR5cGUsIGludCByaWQpCiB7Ci0J dV9sb25nIHN0YXJ0LCBjb3VudDsKKwlidXNfYWRkcl90IHN0YXJ0OworCXVfbG9uZyBjb3VudDsK IAlpbnQgZXJyb3I7CiAKIAllcnJvciA9IEJVU19HRVRfUkVTT1VSQ0UoZGV2aWNlX2dldF9wYXJl bnQoZGV2KSwgZGV2LCB0eXBlLCByaWQsCkBAIC00NDg0LDcgKzQ0ODUsOCBAQAogdV9sb25nCiBi dXNfZ2V0X3Jlc291cmNlX2NvdW50KGRldmljZV90IGRldiwgaW50IHR5cGUsIGludCByaWQpCiB7 Ci0JdV9sb25nIHN0YXJ0LCBjb3VudDsKKwlidXNfYWRkcl90IHN0YXJ0OworCXVfbG9uZyBjb3Vu dDsKIAlpbnQgZXJyb3I7CiAKIAllcnJvciA9IEJVU19HRVRfUkVTT1VSQ0UoZGV2aWNlX2dldF9w YXJlbnQoZGV2KSwgZGV2LCB0eXBlLCByaWQsCkluZGV4OiBzeXMva2Vybi9zdWJyX3JtYW4uYwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBzeXMva2Vybi9zdWJyX3JtYW4uYwkocmV2aXNpb24gMjg3MTg5KQorKysg c3lzL2tlcm4vc3Vicl9ybWFuLmMJKHdvcmtpbmcgY29weSkKQEAgLTkwLDggKzkwLDggQEAKIAlU QUlMUV9FTlRSWShyZXNvdXJjZV9pKQlyX2xpbms7CiAJTElTVF9FTlRSWShyZXNvdXJjZV9pKQly X3NoYXJlbGluazsKIAlMSVNUX0hFQUQoLCByZXNvdXJjZV9pKQkqcl9zaGFyZWhlYWQ7Ci0JdV9s b25nCXJfc3RhcnQ7CS8qIGluZGV4IG9mIHRoZSBmaXJzdCBlbnRyeSBpbiB0aGlzIHJlc291cmNl ICovCi0JdV9sb25nCXJfZW5kOwkJLyogaW5kZXggb2YgdGhlIGxhc3QgZW50cnkgKGluY2x1c2l2 ZSkgKi8KKwlidXNfYWRkcl90CXJfc3RhcnQ7CS8qIGluZGV4IG9mIHRoZSBmaXJzdCBlbnRyeSBp biB0aGlzIHJlc291cmNlICovCisJYnVzX2FkZHJfdAlyX2VuZDsJCS8qIGluZGV4IG9mIHRoZSBs YXN0IGVudHJ5IChpbmNsdXNpdmUpICovCiAJdV9pbnQJcl9mbGFnczsKIAl2b2lkCSpyX3ZpcnR1 YWw7CS8qIHZpcnR1YWwgYWRkcmVzcyBvZiB0aGlzIHJlc291cmNlICovCiAJc3RydWN0IGRldmlj ZSAqcl9kZXY7CS8qIGRldmljZSB3aGljaCBoYXMgYWxsb2NhdGVkIHRoaXMgcmVzb3VyY2UgKi8K QEAgLTEzNSw3ICsxMzUsNyBAQAogCX0KIAogCWlmIChybS0+cm1fc3RhcnQgPT0gMCAmJiBybS0+ cm1fZW5kID09IDApCi0JCXJtLT5ybV9lbmQgPSB+MHVsOworCQlybS0+cm1fZW5kID0gUk1fTUFY X0VORDsKIAlpZiAocm0tPnJtX3R5cGUgPT0gUk1BTl9VTklOSVQpCiAJCXBhbmljKCJybWFuX2lu aXQiKTsKIAlpZiAocm0tPnJtX3R5cGUgPT0gUk1BTl9HQVVHRSkKQEAgLTE1NCwxMyArMTU0LDEz IEBACiB9CiAKIGludAotcm1hbl9tYW5hZ2VfcmVnaW9uKHN0cnVjdCBybWFuICpybSwgdV9sb25n IHN0YXJ0LCB1X2xvbmcgZW5kKQorcm1hbl9tYW5hZ2VfcmVnaW9uKHN0cnVjdCBybWFuICpybSwg YnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQpCiB7CiAJc3RydWN0IHJlc291cmNlX2kg KnIsICpzLCAqdDsKIAlpbnQgcnYgPSAwOwogCi0JRFBSSU5URigoInJtYW5fbWFuYWdlX3JlZ2lv bjogPCVzPiByZXF1ZXN0OiBzdGFydCAlI2x4LCBlbmQgJSNseFxuIiwKLQkgICAgcm0tPnJtX2Rl c2NyLCBzdGFydCwgZW5kKSk7CisJRFBSSU5URigoInJtYW5fbWFuYWdlX3JlZ2lvbjogPCVzPiBy ZXF1ZXN0OiBzdGFydCAlI2xseCwgZW5kICUjbGx4XG4iLAorCSAgICBybS0+cm1fZGVzY3IsICh1 aW50NjRfdClzdGFydCwgKHVpbnQ2NF90KWVuZCkpOwogCWlmIChzdGFydCA8IHJtLT5ybV9zdGFy dCB8fCBlbmQgPiBybS0+cm1fZW5kKQogCQlyZXR1cm4gRUlOVkFMOwogCXIgPSBpbnRfYWxsb2Nf cmVzb3VyY2UoTV9OT1dBSVQpOwpAQCAtMTc0LDcgKzE3NCw3IEBACiAKIAkvKiBTa2lwIGVudHJp ZXMgYmVmb3JlIHVzLiAqLwogCVRBSUxRX0ZPUkVBQ0gocywgJnJtLT5ybV9saXN0LCByX2xpbmsp IHsKLQkJaWYgKHMtPnJfZW5kID09IFVMT05HX01BWCkKKwkJaWYgKHMtPnJfZW5kID09IEJVU19T UEFDRV9NQVhBRERSKQogCQkJYnJlYWs7CiAJCWlmIChzLT5yX2VuZCArIDEgPj0gci0+cl9zdGFy dCkKIAkJCWJyZWFrOwpAQCAtMjc0LDcgKzI3NCw3IEBACiB9CiAKIGludAotcm1hbl9maXJzdF9m cmVlX3JlZ2lvbihzdHJ1Y3Qgcm1hbiAqcm0sIHVfbG9uZyAqc3RhcnQsIHVfbG9uZyAqZW5kKQor cm1hbl9maXJzdF9mcmVlX3JlZ2lvbihzdHJ1Y3Qgcm1hbiAqcm0sIGJ1c19hZGRyX3QgKnN0YXJ0 LCBidXNfYWRkcl90ICplbmQpCiB7CiAJc3RydWN0IHJlc291cmNlX2kgKnI7CiAKQEAgLTI5Miw3 ICsyOTIsNyBAQAogfQogCiBpbnQKLXJtYW5fbGFzdF9mcmVlX3JlZ2lvbihzdHJ1Y3Qgcm1hbiAq cm0sIHVfbG9uZyAqc3RhcnQsIHVfbG9uZyAqZW5kKQorcm1hbl9sYXN0X2ZyZWVfcmVnaW9uKHN0 cnVjdCBybWFuICpybSwgYnVzX2FkZHJfdCAqc3RhcnQsIGJ1c19hZGRyX3QgKmVuZCkKIHsKIAlz dHJ1Y3QgcmVzb3VyY2VfaSAqcjsKIApAQCAtMzExLDcgKzMxMSw3IEBACiAKIC8qIFNocmluayBv ciBleHRlbmQgb25lIG9yIGJvdGggZW5kcyBvZiBhbiBhbGxvY2F0ZWQgcmVzb3VyY2UuICovCiBp bnQKLXJtYW5fYWRqdXN0X3Jlc291cmNlKHN0cnVjdCByZXNvdXJjZSAqcnIsIHVfbG9uZyBzdGFy dCwgdV9sb25nIGVuZCkKK3JtYW5fYWRqdXN0X3Jlc291cmNlKHN0cnVjdCByZXNvdXJjZSAqcnIs IGJ1c19hZGRyX3Qgc3RhcnQsIGJ1c19hZGRyX3QgZW5kKQogewogCXN0cnVjdCByZXNvdXJjZV9p ICpyLCAqcywgKnQsICpuZXc7CiAJc3RydWN0IHJtYW4gKnJtOwpAQCAtNDM0LDE4ICs0MzQsMTkg QEAKICNkZWZpbmUJU0hBUkVfVFlQRShmKQkoZiAmIChSRl9TSEFSRUFCTEUgfCBSRl9QUkVGRVRD SEFCTEUpKQogCiBzdHJ1Y3QgcmVzb3VyY2UgKgotcm1hbl9yZXNlcnZlX3Jlc291cmNlX2JvdW5k KHN0cnVjdCBybWFuICpybSwgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLAotCQkJICAgIHVfbG9u ZyBjb3VudCwgdV9sb25nIGJvdW5kLCB1X2ludCBmbGFncywKK3JtYW5fcmVzZXJ2ZV9yZXNvdXJj ZV9ib3VuZChzdHJ1Y3Qgcm1hbiAqcm0sIGJ1c19hZGRyX3Qgc3RhcnQsIGJ1c19hZGRyX3QgZW5k LAorCQkJICAgIHVfbG9uZyBjb3VudCwgYnVzX2FkZHJfdCBib3VuZCwgdV9pbnQgZmxhZ3MsCiAJ CQkgICAgc3RydWN0IGRldmljZSAqZGV2KQogewogCXVfaW50IG5ld19yZmxhZ3M7CiAJc3RydWN0 IHJlc291cmNlX2kgKnIsICpzLCAqcnY7Ci0JdV9sb25nIHJzdGFydCwgcmVuZCwgYW1hc2ssIGJt YXNrOworCWJ1c19hZGRyX3QgcnN0YXJ0LCByZW5kLCBhbWFzaywgYm1hc2s7CiAKIAlydiA9IE5V TEw7CiAKLQlEUFJJTlRGKCgicm1hbl9yZXNlcnZlX3Jlc291cmNlX2JvdW5kOiA8JXM+IHJlcXVl c3Q6IFslI2x4LCAlI2x4XSwgIgotCSAgICAgICAibGVuZ3RoICUjbHgsIGZsYWdzICV1LCBkZXZp Y2UgJXNcbiIsIHJtLT5ybV9kZXNjciwgc3RhcnQsIGVuZCwKKwlEUFJJTlRGKCgicm1hbl9yZXNl cnZlX3Jlc291cmNlX2JvdW5kOiA8JXM+IHJlcXVlc3Q6IFslI2xseCwgJSNsbHhdLCAiCisJICAg ICAgICJsZW5ndGggJSNseCwgZmxhZ3MgJXUsIGRldmljZSAlc1xuIiwgcm0tPnJtX2Rlc2NyLAor CSAgICAgICAodWludDY0X3Qpc3RhcnQsICh1aW50NjRfdCllbmQsCiAJICAgICAgIGNvdW50LCBm bGFncywKIAkgICAgICAgZGV2ID09IE5VTEwgPyAiPG51bGw+IiA6IGRldmljZV9nZXRfbmFtZXVu aXQoZGV2KSkpOwogCUtBU1NFUlQoKGZsYWdzICYgUkZfRklSU1RTSEFSRSkgPT0gMCwKQEAgLTQ2 NCw5ICs0NjUsMTAgQEAKIAkJZ290byBvdXQ7CiAJfQogCi0JYW1hc2sgPSAoMXVsIDw8IFJGX0FM SUdOTUVOVChmbGFncykpIC0gMTsKLQlLQVNTRVJUKHN0YXJ0IDw9IFVMT05HX01BWCAtIGFtYXNr LAotCSAgICAoInN0YXJ0ICglI2x4KSArIGFtYXNrICglI2x4KSB3b3VsZCB3cmFwIGFyb3VuZCIs IHN0YXJ0LCBhbWFzaykpOworCWFtYXNrID0gKDF1bGwgPDwgUkZfQUxJR05NRU5UKGZsYWdzKSkg LSAxOworCUtBU1NFUlQoc3RhcnQgPD0gQlVTX1NQQUNFX01BWEFERFIgLSBhbWFzaywKKwkgICAg KCJzdGFydCAoJSNsbHgpICsgYW1hc2sgKCUjbGx4KSB3b3VsZCB3cmFwIGFyb3VuZCIsICh1aW50 NjRfdClzdGFydCwKKwkgICAgKHVpbnQ2NF90KWFtYXNrKSk7CiAKIAkvKiBJZiBib3VuZCBpcyAw LCBibWFzayB3aWxsIGFsc28gYmUgMCAqLwogCWJtYXNrID0gfihib3VuZCAtIDEpOwpAQCAtNDc0 LDE5ICs0NzYsMjAgQEAKIAkgKiBGaXJzdCB0cnkgdG8gZmluZCBhbiBhY2NlcHRhYmxlIHRvdGFs bHktdW5zaGFyZWQgcmVnaW9uLgogCSAqLwogCWZvciAocyA9IHI7IHM7IHMgPSBUQUlMUV9ORVhU KHMsIHJfbGluaykpIHsKLQkJRFBSSU5URigoImNvbnNpZGVyaW5nIFslI2x4LCAlI2x4XVxuIiwg cy0+cl9zdGFydCwgcy0+cl9lbmQpKTsKKwkJRFBSSU5URigoImNvbnNpZGVyaW5nIFslI2xseCwg JSNsbHhdXG4iLCAodWludDY0X3Qpcy0+cl9zdGFydCwKKwkJICAgICh1aW50NjRfdClzLT5yX2Vu ZCkpOwogCQkvKgogCQkgKiBUaGUgcmVzb3VyY2UgbGlzdCBpcyBzb3J0ZWQsIHNvIHRoZXJlIGlz IG5vIHBvaW50IGluCiAJCSAqIHNlYXJjaGluZyBmdXJ0aGVyIG9uY2Ugcl9zdGFydCBpcyB0b28g bGFyZ2UuCiAJCSAqLwogCQlpZiAocy0+cl9zdGFydCA+IGVuZCAtIChjb3VudCAtIDEpKSB7Ci0J CQlEUFJJTlRGKCgicy0+cl9zdGFydCAoJSNseCkgKyBjb3VudCAtIDE+IGVuZCAoJSNseClcbiIs Ci0JCQkgICAgcy0+cl9zdGFydCwgZW5kKSk7CisJCQlEUFJJTlRGKCgicy0+cl9zdGFydCAoJSNs bHgpICsgY291bnQgLSAxPiBlbmQgKCUjbGx4KVxuIiwKKwkJCSAgICAodWludDY0X3Qpcy0+cl9z dGFydCwgKHVpbnQ2NF90KWVuZCkpOwogCQkJYnJlYWs7CiAJCX0KLQkJaWYgKHMtPnJfc3RhcnQg PiBVTE9OR19NQVggLSBhbWFzaykgewotCQkJRFBSSU5URigoInMtPnJfc3RhcnQgKCUjbHgpICsg YW1hc2sgKCUjbHgpIHRvbyBsYXJnZVxuIiwKLQkJCSAgICBzLT5yX3N0YXJ0LCBhbWFzaykpOwor CQlpZiAocy0+cl9zdGFydCA+IEJVU19TUEFDRV9NQVhBRERSIC0gYW1hc2spIHsKKwkJCURQUklO VEYoKCJzLT5yX3N0YXJ0ICglI2xseCkgKyBhbWFzayAoJSNsbHgpIHRvbyBsYXJnZVxuIiwKKwkJ CSAgICAodWludDY0X3Qpcy0+cl9zdGFydCwgKHVpbnQ2NF90KWFtYXNrKSk7CiAJCQlicmVhazsK IAkJfQogCQlpZiAocy0+cl9mbGFncyAmIFJGX0FMTE9DQVRFRCkgewpAQCAtNDkzLDcgKzQ5Niw3 IEBACiAJCQlEUFJJTlRGKCgicmVnaW9uIGlzIGFsbG9jYXRlZFxuIikpOwogCQkJY29udGludWU7 CiAJCX0KLQkJcnN0YXJ0ID0gdWxtYXgocy0+cl9zdGFydCwgc3RhcnQpOworCQlyc3RhcnQgPSBx bWF4KHMtPnJfc3RhcnQsIHN0YXJ0KTsKIAkJLyoKIAkJICogVHJ5IHRvIGZpbmQgYSByZWdpb24g YnkgYWRqdXN0aW5nIHRvIGJvdW5kYXJ5IGFuZCBhbGlnbm1lbnQKIAkJICogdW50aWwgYm90aCBj b25kaXRpb25zIGFyZSBzYXRpc2ZpZWQuIFRoaXMgaXMgbm90IGFuIG9wdGltYWwKQEAgLTUwNSwx NyArNTA4LDE4IEBACiAJCQkJcnN0YXJ0ICs9IGJvdW5kIC0gKHJzdGFydCAmIH5ibWFzayk7CiAJ CX0gd2hpbGUgKChyc3RhcnQgJiBhbWFzaykgIT0gMCAmJiByc3RhcnQgPCBlbmQgJiYKIAkJICAg IHJzdGFydCA8IHMtPnJfZW5kKTsKLQkJcmVuZCA9IHVsbWluKHMtPnJfZW5kLCB1bG1heChyc3Rh cnQgKyBjb3VudCAtIDEsIGVuZCkpOworCQlyZW5kID0gcW1pbihzLT5yX2VuZCwgcW1heChyc3Rh cnQgKyBjb3VudCAtIDEsIGVuZCkpOwogCQlpZiAocnN0YXJ0ID4gcmVuZCkgewogCQkJRFBSSU5U RigoImFkanVzdGVkIHN0YXJ0IGV4Y2VlZHMgZW5kXG4iKSk7CiAJCQljb250aW51ZTsKIAkJfQot CQlEUFJJTlRGKCgidHJ1bmNhdGVkIHJlZ2lvbjogWyUjbHgsICUjbHhdOyBzaXplICUjbHggKHJl cXVlc3RlZCAlI2x4KVxuIiwKLQkJICAgICAgIHJzdGFydCwgcmVuZCwgKHJlbmQgLSByc3RhcnQg KyAxKSwgY291bnQpKTsKKwkJRFBSSU5URigoInRydW5jYXRlZCByZWdpb246IFslI2xseCwgJSNs bHhdOyBzaXplICUjbHggKHJlcXVlc3RlZCAlI2x4KVxuIiwKKwkJICAgICAgICh1aW50NjRfdCly c3RhcnQsICh1aW50NjRfdClyZW5kLCAodV9sb25nKShyZW5kIC0gcnN0YXJ0ICsgMSksIGNvdW50 KSk7CiAKIAkJaWYgKChyZW5kIC0gcnN0YXJ0ICsgMSkgPj0gY291bnQpIHsKLQkJCURQUklOVEYo KCJjYW5kaWRhdGUgcmVnaW9uOiBbJSNseCwgJSNseF0sIHNpemUgJSNseFxuIiwKLQkJCSAgICAg ICByc3RhcnQsIHJlbmQsIChyZW5kIC0gcnN0YXJ0ICsgMSkpKTsKKwkJCURQUklOVEYoKCJjYW5k aWRhdGUgcmVnaW9uOiBbJSNsbHgsICUjbGx4XSwgc2l6ZSAlI2x4XG4iLAorCQkJICAgICAgICh1 aW50NjRfdClyc3RhcnQsICh1aW50NjRfdClyZW5kLAorCQkJICAgICAgICh1X2xvbmcpKHJlbmQg LSByc3RhcnQgKyAxKSkpOwogCQkJaWYgKChzLT5yX2VuZCAtIHMtPnJfc3RhcnQgKyAxKSA9PSBj b3VudCkgewogCQkJCURQUklOVEYoKCJjYW5kaWRhdGUgcmVnaW9uIGlzIGVudGlyZSBjaHVua1xu IikpOwogCQkJCXJ2ID0gczsKQEAgLTU0NSwxMCArNTQ5LDEwIEBACiAKIAkJCWlmIChzLT5yX3N0 YXJ0IDwgcnYtPnJfc3RhcnQgJiYgcy0+cl9lbmQgPiBydi0+cl9lbmQpIHsKIAkJCQlEUFJJTlRG KCgic3BsaXR0aW5nIHJlZ2lvbiBpbiB0aHJlZSBwYXJ0czogIgotCQkJCSAgICAgICAiWyUjbHgs ICUjbHhdOyBbJSNseCwgJSNseF07IFslI2x4LCAlI2x4XVxuIiwKLQkJCQkgICAgICAgcy0+cl9z dGFydCwgcnYtPnJfc3RhcnQgLSAxLAotCQkJCSAgICAgICBydi0+cl9zdGFydCwgcnYtPnJfZW5k LAotCQkJCSAgICAgICBydi0+cl9lbmQgKyAxLCBzLT5yX2VuZCkpOworCQkJCSAgICAgICAiWyUj bGx4LCAlI2xseF07IFslI2xseCwgJSNsbHhdOyBbJSNsbHgsICUjbGx4XVxuIiwKKwkJCQkgICAg ICAgKHVpbnQ2NF90KXMtPnJfc3RhcnQsICh1aW50NjRfdClydi0+cl9zdGFydCAtIDEsCisJCQkJ ICAgICAgICh1aW50NjRfdClydi0+cl9zdGFydCwgKHVpbnQ2NF90KXJ2LT5yX2VuZCwKKwkJCQkg ICAgICAgKHVpbnQ2NF90KXJ2LT5yX2VuZCArIDEsICh1aW50NjRfdClzLT5yX2VuZCkpOwogCQkJ CS8qCiAJCQkJICogV2UgYXJlIGFsbG9jYXRpbmcgaW4gdGhlIG1pZGRsZS4KIAkJCQkgKi8KQEAg LTY0MSw4ICs2NDUsOCBAQAogfQogCiBzdHJ1Y3QgcmVzb3VyY2UgKgotcm1hbl9yZXNlcnZlX3Jl c291cmNlKHN0cnVjdCBybWFuICpybSwgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB1X2xvbmcg Y291bnQsCi0JCSAgICAgIHVfaW50IGZsYWdzLCBzdHJ1Y3QgZGV2aWNlICpkZXYpCitybWFuX3Jl c2VydmVfcmVzb3VyY2Uoc3RydWN0IHJtYW4gKnJtLCBidXNfYWRkcl90IHN0YXJ0LCBidXNfYWRk cl90IGVuZCwKKwkJICAgICAgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncywgc3RydWN0IGRldmlj ZSAqZGV2KQogewogCiAJcmV0dXJuIChybWFuX3Jlc2VydmVfcmVzb3VyY2VfYm91bmQocm0sIHN0 YXJ0LCBlbmQsIGNvdW50LCAwLCBmbGFncywKQEAgLTgwMywxMyArODA3LDEzIEBACiB9CiAKIHZv aWQKLXJtYW5fc2V0X3N0YXJ0KHN0cnVjdCByZXNvdXJjZSAqciwgdV9sb25nIHN0YXJ0KQorcm1h bl9zZXRfc3RhcnQoc3RydWN0IHJlc291cmNlICpyLCBidXNfYWRkcl90IHN0YXJ0KQogewogCiAJ ci0+X19yX2ktPnJfc3RhcnQgPSBzdGFydDsKIH0KIAotdV9sb25nCitidXNfYWRkcl90CiBybWFu X2dldF9zdGFydChzdHJ1Y3QgcmVzb3VyY2UgKnIpCiB7CiAKQEAgLTgxNywxMyArODIxLDEzIEBA CiB9CiAKIHZvaWQKLXJtYW5fc2V0X2VuZChzdHJ1Y3QgcmVzb3VyY2UgKnIsIHVfbG9uZyBlbmQp CitybWFuX3NldF9lbmQoc3RydWN0IHJlc291cmNlICpyLCBidXNfYWRkcl90IGVuZCkKIHsKIAog CXItPl9fcl9pLT5yX2VuZCA9IGVuZDsKIH0KIAotdV9sb25nCitidXNfYWRkcl90CiBybWFuX2dl dF9lbmQoc3RydWN0IHJlc291cmNlICpyKQogewogCkBAIC04MzAsNyArODM0LDcgQEAKIAlyZXR1 cm4gKHItPl9fcl9pLT5yX2VuZCk7CiB9CiAKLXVfbG9uZworYnVzX3NpemVfdAogcm1hbl9nZXRf c2l6ZShzdHJ1Y3QgcmVzb3VyY2UgKnIpCiB7CiAKSW5kZXg6IHN5cy9wb3dlcnBjL2luY2x1ZGUv YnVzLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQotLS0gc3lzL3Bvd2VycGMvaW5jbHVkZS9idXMuaAkocmV2aXNpb24g Mjg3MTg5KQorKysgc3lzL3Bvd2VycGMvaW5jbHVkZS9idXMuaAkod29ya2luZyBjb3B5KQpAQCAt NzksOSArNzksMTQgQEAKICNkZWZpbmUgQlVTX1NQQUNFX01BWEFERFIgCTB4RkZGRkZGRkZGRkZG RkZGRlVMCiAjZGVmaW5lIEJVU19TUEFDRV9NQVhTSVpFIAkweEZGRkZGRkZGRkZGRkZGRkZVTAog I2Vsc2UKKyNpZmRlZiBCT09LRQorI2RlZmluZSBCVVNfU1BBQ0VfTUFYQUREUiAJMHhGRkZGRkZG RkZVTAorI2RlZmluZSBCVVNfU1BBQ0VfTUFYU0laRSAJMHhGRkZGRkZGRlVMCisjZWxzZQogI2Rl ZmluZSBCVVNfU1BBQ0VfTUFYQUREUiAJMHhGRkZGRkZGRlVMCiAjZGVmaW5lIEJVU19TUEFDRV9N QVhTSVpFIAkweEZGRkZGRkZGVUwKICNlbmRpZgorI2VuZGlmCiAKICNkZWZpbmUJQlVTX1NQQUNF X01BUF9DQUNIRUFCTEUJCTB4MDEKICNkZWZpbmUJQlVTX1NQQUNFX01BUF9MSU5FQVIJCTB4MDIK SW5kZXg6IHN5cy9wb3dlcnBjL2luY2x1ZGUvcGxhdGZvcm0uaAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv cG93ZXJwYy9pbmNsdWRlL3BsYXRmb3JtLmgJKHJldmlzaW9uIDI4NzE4OSkKKysrIHN5cy9wb3dl cnBjL2luY2x1ZGUvcGxhdGZvcm0uaAkod29ya2luZyBjb3B5KQpAQCAtMzksOCArMzksOCBAQAog I2luY2x1ZGUgPG1hY2hpbmUvcGNwdS5oPgogCiBzdHJ1Y3QgbWVtX3JlZ2lvbiB7Ci0Jdm1fb2Zm c2V0X3QJbXJfc3RhcnQ7Ci0Jdm1fc2l6ZV90CW1yX3NpemU7CisJdWludDY0X3QJbXJfc3RhcnQ7 CisJdWludDY0X3QJbXJfc2l6ZTsKIH07CiAKIHZvaWQJbWVtX3JlZ2lvbnMoc3RydWN0IG1lbV9y ZWdpb24gKiosIGludCAqLCBzdHJ1Y3QgbWVtX3JlZ2lvbiAqKiwgaW50ICopOwpJbmRleDogc3lz L3Bvd2VycGMvbXBjODV4eC9sYmMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvcG93ZXJwYy9tcGM4NXh4 L2xiYy5jCShyZXZpc2lvbiAyODcxODkpCisrKyBzeXMvcG93ZXJwYy9tcGM4NXh4L2xiYy5jCSh3 b3JraW5nIGNvcHkpCkBAIC02OSw3ICs2OSw3IEBACiBzdGF0aWMgaW50IGxiY19hdHRhY2goZGV2 aWNlX3QpOwogc3RhdGljIGludCBsYmNfc2h1dGRvd24oZGV2aWNlX3QpOwogc3RhdGljIHN0cnVj dCByZXNvdXJjZSAqbGJjX2FsbG9jX3Jlc291cmNlKGRldmljZV90LCBkZXZpY2VfdCwgaW50LCBp bnQgKiwKLSAgICB1X2xvbmcsIHVfbG9uZywgdV9sb25nLCB1X2ludCk7CisgICAgYnVzX2FkZHJf dCwgYnVzX2FkZHJfdCwgdV9sb25nLCB1X2ludCk7CiBzdGF0aWMgaW50IGxiY19wcmludF9jaGls ZChkZXZpY2VfdCwgZGV2aWNlX3QpOwogc3RhdGljIGludCBsYmNfcmVsZWFzZV9yZXNvdXJjZShk ZXZpY2VfdCwgZGV2aWNlX3QsIGludCwgaW50LAogICAgIHN0cnVjdCByZXNvdXJjZSAqKTsKQEAg LTExMyw3ICsxMTMsOCBAQAogCiBkZXZjbGFzc190IGxiY19kZXZjbGFzczsKIAotRFJJVkVSX01P RFVMRShsYmMsIG9md2J1cywgbGJjX2RyaXZlciwgbGJjX2RldmNsYXNzLCAwLCAwKTsKK0VBUkxZ X0RSSVZFUl9NT0RVTEUobGJjLCBvZndidXMsIGxiY19kcml2ZXIsIGxiY19kZXZjbGFzcywgMCwg MCwKKyAgICBCVVNfUEFTU19CVVMgKyBCVVNfUEFTU19PUkRFUl9NSURETEUpOwogCiAvKgogICog Q2FsY3VsYXRlIGFkZHJlc3MgbWFzayB1c2VkIGJ5IE9SKG4pIHJlZ2lzdGVycy4gVXNlIG1lbW9y eSByZWdpb24gc2l6ZSB0bwpAQCAtMzU0LDcgKzM1NSw3IEBACiBmZHRfbGJjX3JlZ19kZWNvZGUo cGhhbmRsZV90IG5vZGUsIHN0cnVjdCBsYmNfc29mdGMgKnNjLAogICAgIHN0cnVjdCBsYmNfZGV2 aW5mbyAqZGkpCiB7Ci0JdV9sb25nIHN0YXJ0LCBlbmQsIGNvdW50OworCXVpbnQ2NF90IHN0YXJ0 LCBlbmQsIGNvdW50OwogCXBjZWxsX3QgKnJlZywgKnJlZ3B0cjsKIAlwY2VsbF90IGFkZHJfY2Vs bHMsIHNpemVfY2VsbHM7CiAJaW50IHR1cGxlX3NpemUsIHR1cGxlczsKQEAgLTM5MSw4ICszOTIs OCBAQAogCQlzdGFydCA9IHNjLT5zY19iYW5rc1tiYW5rXS5rdmEgKyBzdGFydDsKIAkJZW5kID0g c3RhcnQgKyBjb3VudCAtIDE7CiAKLQkJZGVidWdmKCJyZWcgYWRkciBiYW5rID0gJWQsIHN0YXJ0 ID0gJWx4LCBlbmQgPSAlbHgsICIKLQkJICAgICJjb3VudCA9ICVseFxuIiwgYmFuaywgc3RhcnQs IGVuZCwgY291bnQpOworCQlkZWJ1Z2YoInJlZyBhZGRyIGJhbmsgPSAlZCwgc3RhcnQgPSAlbGx4 LCBlbmQgPSAlbGx4LCAiCisJCSAgICAiY291bnQgPSAlbGx4XG4iLCBiYW5rLCBzdGFydCwgZW5k LCBjb3VudCk7CiAKIAkJLyogVXNlIGJhbmsgKENTKSBjZWxsIGFzIHJpZC4gKi8KIAkJcmVzb3Vy Y2VfbGlzdF9hZGQoJmRpLT5kaV9yZXMsIFNZU19SRVNfTUVNT1JZLCBiYW5rLCBzdGFydCwKQEAg LTQzNCw3ICs0MzUsNyBAQAogCXN0cnVjdCBsYmNfc29mdGMgKnNjOwogCXN0cnVjdCBsYmNfZGV2 aW5mbyAqZGk7CiAJc3RydWN0IHJtYW4gKnJtOwotCXVfbG9uZyBvZmZzZXQsIHN0YXJ0LCBzaXpl OworCXVpbnQ2NF90IG9mZnNldCwgc3RhcnQsIHNpemU7CiAJZGV2aWNlX3QgY2RldjsKIAlwaGFu ZGxlX3Qgbm9kZSwgY2hpbGQ7CiAJcGNlbGxfdCAqcmFuZ2VzLCAqcmFuZ2VzcHRyOwpAQCAtNjYz LDcgKzY2NCw3IEBACiAKIHN0YXRpYyBzdHJ1Y3QgcmVzb3VyY2UgKgogbGJjX2FsbG9jX3Jlc291 cmNlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgKnJpZCwKLSAg ICB1X2xvbmcgc3RhcnQsIHVfbG9uZyBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpCisg ICAgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQsIHVfbG9uZyBjb3VudCwgdV9pbnQg ZmxhZ3MpCiB7CiAJc3RydWN0IGxiY19zb2Z0YyAqc2M7CiAJc3RydWN0IGxiY19kZXZpbmZvICpk aTsKSW5kZXg6IHN5cy9wb3dlcnBjL29mdy9vZndfcGNpLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL3Bv d2VycGMvb2Z3L29md19wY2kuYwkocmV2aXNpb24gMjg3MTg5KQorKysgc3lzL3Bvd2VycGMvb2Z3 L29md19wY2kuYwkod29ya2luZyBjb3B5KQpAQCAtNjIsOCArNjIsOCBAQAogc3RhdGljIGludAkJ b2Z3X3BjaV9yZWFkX2l2YXIoZGV2aWNlX3QsIGRldmljZV90LCBpbnQsCiAJCQkgICAgdWludHB0 cl90ICopOwogc3RhdGljIHN0cnVjdAkJcmVzb3VyY2UgKiBvZndfcGNpX2FsbG9jX3Jlc291cmNl KGRldmljZV90IGJ1cywKLQkJCSAgICBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlk LCB1X2xvbmcgc3RhcnQsCi0JCQkgICAgdV9sb25nIGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBm bGFncyk7CisJCQkgICAgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgKnJpZCwgYnVzX2Fk ZHJfdCBzdGFydCwKKwkJCSAgICBidXNfYWRkcl90IGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBm bGFncyk7CiBzdGF0aWMgaW50CQlvZndfcGNpX3JlbGVhc2VfcmVzb3VyY2UoZGV2aWNlX3QgYnVz LCBkZXZpY2VfdCBjaGlsZCwKICAgICAJCQkgICAgaW50IHR5cGUsIGludCByaWQsIHN0cnVjdCBy ZXNvdXJjZSAqcmVzKTsKIHN0YXRpYyBpbnQJCW9md19wY2lfYWN0aXZhdGVfcmVzb3VyY2UoZGV2 aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwKQEAgLTcyLDggKzcyLDggQEAKICAgICAJCQkgICAg ZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlkLAogICAgIAkJCSAgICBzdHJ1Y3QgcmVz b3VyY2UgKnJlcyk7CiBzdGF0aWMgaW50CQlvZndfcGNpX2FkanVzdF9yZXNvdXJjZShkZXZpY2Vf dCBidXMsIGRldmljZV90IGNoaWxkLAotCQkJICAgIGludCB0eXBlLCBzdHJ1Y3QgcmVzb3VyY2Ug KnJlcywgdV9sb25nIHN0YXJ0LAotCQkJICAgIHVfbG9uZyBlbmQpOworCQkJICAgIGludCB0eXBl LCBzdHJ1Y3QgcmVzb3VyY2UgKnJlcywgYnVzX2FkZHJfdCBzdGFydCwKKwkJCSAgICBidXNfYWRk cl90IGVuZCk7CiAKIC8qCiAgKiBwY2liIGludGVyZmFjZS4KQEAgLTMwNyw3ICszMDcsNyBAQAog CiBzdGF0aWMgc3RydWN0IHJlc291cmNlICoKIG9md19wY2lfYWxsb2NfcmVzb3VyY2UoZGV2aWNl X3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlkLAotICAgIHVfbG9uZyBz dGFydCwgdV9sb25nIGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKKyAgICBidXNfYWRk cl90IHN0YXJ0LCBidXNfYWRkcl90IGVuZCwgdV9sb25nIGNvdW50LCB1X2ludCBmbGFncykKIHsK IAlzdHJ1Y3QJCQlvZndfcGNpX3NvZnRjICpzYzsKIAlzdHJ1Y3QJCQlyZXNvdXJjZSAqcnY7CkBA IC00NTMsNyArNDUzLDcgQEAKIAogc3RhdGljIGludAogb2Z3X3BjaV9hZGp1c3RfcmVzb3VyY2Uo ZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsCi0gICAgc3RydWN0IHJlc291 cmNlICpyZXMsIHVfbG9uZyBzdGFydCwgdV9sb25nIGVuZCkKKyAgICBzdHJ1Y3QgcmVzb3VyY2Ug KnJlcywgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQpCiB7CiAJc3RydWN0IHJtYW4g KnJtID0gTlVMTDsKIAlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2MgPSBkZXZpY2VfZ2V0X3NvZnRj KGJ1cyk7CkluZGV4OiBzeXMvcG93ZXJwYy9wb3dlcnBjL25leHVzLmMKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g c3lzL3Bvd2VycGMvcG93ZXJwYy9uZXh1cy5jCShyZXZpc2lvbiAyODcxODkpCisrKyBzeXMvcG93 ZXJwYy9wb3dlcnBjL25leHVzLmMJKHdvcmtpbmcgY29weSkKQEAgLTE4OSwxMyArMTg5LDEzIEBA CiB7CiAKIAlpZiAodHlwZSA9PSBTWVNfUkVTX01FTU9SWSkgewotCQl2bV9vZmZzZXRfdCBzdGFy dDsKKwkJdm1fcGFkZHJfdCBzdGFydDsKIAkJdm9pZCAqcDsKIAotCQlzdGFydCA9ICh2bV9vZmZz ZXRfdCkgcm1hbl9nZXRfc3RhcnQocik7CisJCXN0YXJ0ID0gcm1hbl9nZXRfc3RhcnQocik7CiAJ CWlmIChib290dmVyYm9zZSkKLQkJCXByaW50ZigibmV4dXMgbWFwZGV2OiBzdGFydCAlengsIGxl biAlbGRcbiIsIHN0YXJ0LAotCQkJICAgIHJtYW5fZ2V0X3NpemUocikpOworCQkJcHJpbnRmKCJu ZXh1cyBtYXBkZXY6IHN0YXJ0ICVsbHgsIGxlbiAlbGRcbiIsCisJCQkgICAgKHVpbnQ2NF90KXN0 YXJ0LCBybWFuX2dldF9zaXplKHIpKTsKIAogCQlwID0gcG1hcF9tYXBkZXYoc3RhcnQsICh2bV9z aXplX3QpIHJtYW5fZ2V0X3NpemUocikpOwogCQlpZiAocCA9PSBOVUxMKQpJbmRleDogc3lzL3Bv d2VycGMvcG93ZXJwYy9wbGF0Zm9ybS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9wb3dlcnBjL3Bvd2Vy cGMvcGxhdGZvcm0uYwkocmV2aXNpb24gMjg3MTg5KQorKysgc3lzL3Bvd2VycGMvcG93ZXJwYy9w bGF0Zm9ybS5jCSh3b3JraW5nIGNvcHkpCkBAIC04Niw4ICs4Niw4IEBACiBtZW1yX21lcmdlKHN0 cnVjdCBtZW1fcmVnaW9uICpmcm9tLCBzdHJ1Y3QgbWVtX3JlZ2lvbiAqdG8pCiB7CiAJdm1fb2Zm c2V0X3QgZW5kOwotCWVuZCA9IHVsbWF4KHRvLT5tcl9zdGFydCArIHRvLT5tcl9zaXplLCBmcm9t LT5tcl9zdGFydCArIGZyb20tPm1yX3NpemUpOwotCXRvLT5tcl9zdGFydCA9IHVsbWluKGZyb20t Pm1yX3N0YXJ0LCB0by0+bXJfc3RhcnQpOworCWVuZCA9IHFtYXgodG8tPm1yX3N0YXJ0ICsgdG8t Pm1yX3NpemUsIGZyb20tPm1yX3N0YXJ0ICsgZnJvbS0+bXJfc2l6ZSk7CisJdG8tPm1yX3N0YXJ0 ID0gcW1pbihmcm9tLT5tcl9zdGFydCwgdG8tPm1yX3N0YXJ0KTsKIAl0by0+bXJfc2l6ZSA9IGVu ZCAtIHRvLT5tcl9zdGFydDsKIH0KIApJbmRleDogc3lzL3N5cy9idXMuaAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBzeXMvc3lzL2J1cy5oCShyZXZpc2lvbiAyODcxODkpCisrKyBzeXMvc3lzL2J1cy5oCSh3b3Jr aW5nIGNvcHkpCkBAIC0yOSw2ICsyOSw3IEBACiAjaWZuZGVmIF9TWVNfQlVTX0hfCiAjZGVmaW5l IF9TWVNfQlVTX0hfCiAKKyNpbmNsdWRlIDxtYWNoaW5lL19idXMuaD4KICNpbmNsdWRlIDxtYWNo aW5lL19saW1pdHMuaD4KICNpbmNsdWRlIDxzeXMvX2J1c19kbWEuaD4KICNpbmNsdWRlIDxzeXMv aW9jY29tLmg+CkBAIC0yOTIsOCArMjkzLDggQEAKIAlpbnQJcmlkOwkJCS8qKjwgQGJyaWVmIHJl c291cmNlIGlkZW50aWZpZXIgKi8KIAlpbnQJZmxhZ3M7CQkJLyoqPCBAYnJpZWYgcmVzb3VyY2Ug ZmxhZ3MgKi8KIAlzdHJ1Y3QJcmVzb3VyY2UgKnJlczsJCS8qKjwgQGJyaWVmIHRoZSByZWFsIHJl c291cmNlIHdoZW4gYWxsb2NhdGVkICovCi0JdV9sb25nCXN0YXJ0OwkJCS8qKjwgQGJyaWVmIHN0 YXJ0IG9mIHJlc291cmNlIHJhbmdlICovCi0JdV9sb25nCWVuZDsJCQkvKio8IEBicmllZiBlbmQg b2YgcmVzb3VyY2UgcmFuZ2UgKi8KKwlidXNfYWRkcl90CXN0YXJ0OwkJLyoqPCBAYnJpZWYgc3Rh cnQgb2YgcmVzb3VyY2UgcmFuZ2UgKi8KKwlidXNfYWRkcl90CWVuZDsJCS8qKjwgQGJyaWVmIGVu ZCBvZiByZXNvdXJjZSByYW5nZSAqLwogCXVfbG9uZwljb3VudDsJCQkvKio8IEBicmllZiBjb3Vu dCB3aXRoaW4gcmFuZ2UgKi8KIH07CiBTVEFJTFFfSEVBRChyZXNvdXJjZV9saXN0LCByZXNvdXJj ZV9saXN0X2VudHJ5KTsKQEAgLTMwNywxMCArMzA4LDEwIEBACiBzdHJ1Y3QgcmVzb3VyY2VfbGlz dF9lbnRyeSAqCiAJcmVzb3VyY2VfbGlzdF9hZGQoc3RydWN0IHJlc291cmNlX2xpc3QgKnJsLAog CQkJICBpbnQgdHlwZSwgaW50IHJpZCwKLQkJCSAgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLCB1 X2xvbmcgY291bnQpOworCQkJICBidXNfYWRkcl90IHN0YXJ0LCBidXNfYWRkcl90IGVuZCwgdV9s b25nIGNvdW50KTsKIGludAlyZXNvdXJjZV9saXN0X2FkZF9uZXh0KHN0cnVjdCByZXNvdXJjZV9s aXN0ICpybCwKIAkJCSAgaW50IHR5cGUsCi0JCQkgIHVfbG9uZyBzdGFydCwgdV9sb25nIGVuZCwg dV9sb25nIGNvdW50KTsKKwkJCSAgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2FkZHJfdCBlbmQsIHVf bG9uZyBjb3VudCk7CiBpbnQJcmVzb3VyY2VfbGlzdF9idXN5KHN0cnVjdCByZXNvdXJjZV9saXN0 ICpybCwKIAkJCSAgIGludCB0eXBlLCBpbnQgcmlkKTsKIGludAlyZXNvdXJjZV9saXN0X3Jlc2Vy dmVkKHN0cnVjdCByZXNvdXJjZV9saXN0ICpybCwgaW50IHR5cGUsIGludCByaWQpOwpAQCAtMzIz LDcgKzMyNCw3IEBACiAJcmVzb3VyY2VfbGlzdF9hbGxvYyhzdHJ1Y3QgcmVzb3VyY2VfbGlzdCAq cmwsCiAJCQkgICAgZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwKIAkJCSAgICBpbnQgdHlw ZSwgaW50ICpyaWQsCi0JCQkgICAgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kLAorCQkJICAgIGJ1 c19hZGRyX3Qgc3RhcnQsIGJ1c19hZGRyX3QgZW5kLAogCQkJICAgIHVfbG9uZyBjb3VudCwgdV9p bnQgZmxhZ3MpOwogaW50CXJlc291cmNlX2xpc3RfcmVsZWFzZShzdHJ1Y3QgcmVzb3VyY2VfbGlz dCAqcmwsCiAJCQkgICAgICBkZXZpY2VfdCBidXMsIGRldmljZV90IGNoaWxkLApAQCAtMzM1LDcg KzMzNiw3IEBACiAJcmVzb3VyY2VfbGlzdF9yZXNlcnZlKHN0cnVjdCByZXNvdXJjZV9saXN0ICpy bCwKIAkJCSAgICAgIGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsCiAJCQkgICAgICBpbnQg dHlwZSwgaW50ICpyaWQsCi0JCQkgICAgICB1X2xvbmcgc3RhcnQsIHVfbG9uZyBlbmQsCisJCQkg ICAgICBidXNfYWRkcl90IHN0YXJ0LCBidXNfYWRkcl90IGVuZCwKIAkJCSAgICAgIHVfbG9uZyBj b3VudCwgdV9pbnQgZmxhZ3MpOwogaW50CXJlc291cmNlX2xpc3RfdW5yZXNlcnZlKHN0cnVjdCBy ZXNvdXJjZV9saXN0ICpybCwKIAkJCQlkZXZpY2VfdCBidXMsIGRldmljZV90IGNoaWxkLApAQCAt MzYyLDExICszNjMsMTEgQEAKIAlidXNfZ2VuZXJpY19hZGRfY2hpbGQoZGV2aWNlX3QgZGV2LCB1 X2ludCBvcmRlciwgY29uc3QgY2hhciAqbmFtZSwKIAkJCSAgICAgIGludCB1bml0KTsKIGludAli dXNfZ2VuZXJpY19hZGp1c3RfcmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwg aW50IHR5cGUsCi0JCQkJICAgIHN0cnVjdCByZXNvdXJjZSAqciwgdV9sb25nIHN0YXJ0LAotCQkJ CSAgICB1X2xvbmcgZW5kKTsKKwkJCQkgICAgc3RydWN0IHJlc291cmNlICpyLCBidXNfYWRkcl90 IHN0YXJ0LAorCQkJCSAgICBidXNfYWRkcl90IGVuZCk7CiBzdHJ1Y3QgcmVzb3VyY2UgKgogCWJ1 c19nZW5lcmljX2FsbG9jX3Jlc291cmNlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGlu dCB0eXBlLAotCQkJCSAgIGludCAqcmlkLCB1X2xvbmcgc3RhcnQsIHVfbG9uZyBlbmQsCisJCQkJ ICAgaW50ICpyaWQsIGJ1c19hZGRyX3Qgc3RhcnQsIGJ1c19hZGRyX3QgZW5kLAogCQkJCSAgIHVf bG9uZyBjb3VudCwgdV9pbnQgZmxhZ3MpOwogaW50CWJ1c19nZW5lcmljX2F0dGFjaChkZXZpY2Vf dCBkZXYpOwogaW50CWJ1c19nZW5lcmljX2JpbmRfaW50cihkZXZpY2VfdCBkZXYsIGRldmljZV90 IGNoaWxkLApAQCAtNDA1LDExICs0MDYsMTEgQEAKIAogc3RydWN0IHJlc291cmNlICoKIAlidXNf Z2VuZXJpY19ybF9hbGxvY19yZXNvdXJjZSAoZGV2aWNlX3QsIGRldmljZV90LCBpbnQsIGludCAq LAotCQkJCSAgICAgICB1X2xvbmcsIHVfbG9uZywgdV9sb25nLCB1X2ludCk7CisJCQkJICAgICAg IGJ1c19hZGRyX3QsIGJ1c19hZGRyX3QsIHVfbG9uZywgdV9pbnQpOwogdm9pZAlidXNfZ2VuZXJp Y19ybF9kZWxldGVfcmVzb3VyY2UgKGRldmljZV90LCBkZXZpY2VfdCwgaW50LCBpbnQpOwotaW50 CWJ1c19nZW5lcmljX3JsX2dldF9yZXNvdXJjZSAoZGV2aWNlX3QsIGRldmljZV90LCBpbnQsIGlu dCwgdV9sb25nICosCitpbnQJYnVzX2dlbmVyaWNfcmxfZ2V0X3Jlc291cmNlIChkZXZpY2VfdCwg ZGV2aWNlX3QsIGludCwgaW50LCBidXNfYWRkcl90ICosCiAJCQkJICAgICB1X2xvbmcgKik7Ci1p bnQJYnVzX2dlbmVyaWNfcmxfc2V0X3Jlc291cmNlIChkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwg aW50LCB1X2xvbmcsCitpbnQJYnVzX2dlbmVyaWNfcmxfc2V0X3Jlc291cmNlIChkZXZpY2VfdCwg ZGV2aWNlX3QsIGludCwgaW50LCBidXNfYWRkcl90LAogCQkJCSAgICAgdV9sb25nKTsKIGludAli dXNfZ2VuZXJpY19ybF9yZWxlYXNlX3Jlc291cmNlIChkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwg aW50LAogCQkJCQkgc3RydWN0IHJlc291cmNlICopOwpAQCAtNDM5LDEwICs0NDAsMTAgQEAKIAkJ CSAgICAgIHN0cnVjdCByZXNvdXJjZSAqKnJlcyk7CiAKIGludAlidXNfYWRqdXN0X3Jlc291cmNl KGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgc3RydWN0IHJlc291cmNlICpyLAotCQkJICAgIHVf bG9uZyBzdGFydCwgdV9sb25nIGVuZCk7CisJCQkgICAgYnVzX2FkZHJfdCBzdGFydCwgYnVzX2Fk ZHJfdCBlbmQpOwogc3RydWN0CXJlc291cmNlICpidXNfYWxsb2NfcmVzb3VyY2UoZGV2aWNlX3Qg ZGV2LCBpbnQgdHlwZSwgaW50ICpyaWQsCi0JCQkJICAgICB1X2xvbmcgc3RhcnQsIHVfbG9uZyBl bmQsIHVfbG9uZyBjb3VudCwKLQkJCQkgICAgIHVfaW50IGZsYWdzKTsKKwkJCQkgICAgIGJ1c19h ZGRyX3Qgc3RhcnQsIGJ1c19hZGRyX3QgZW5kLAorCQkJCSAgICAgdV9sb25nIGNvdW50LCB1X2lu dCBmbGFncyk7CiBpbnQJYnVzX2FjdGl2YXRlX3Jlc291cmNlKGRldmljZV90IGRldiwgaW50IHR5 cGUsIGludCByaWQsCiAJCQkgICAgICBzdHJ1Y3QgcmVzb3VyY2UgKnIpOwogaW50CWJ1c19kZWFj dGl2YXRlX3Jlc291cmNlKGRldmljZV90IGRldiwgaW50IHR5cGUsIGludCByaWQsCkBAIC00NjAs MTAgKzQ2MSwxMCBAQAogaW50CWJ1c19kZXNjcmliZV9pbnRyKGRldmljZV90IGRldiwgc3RydWN0 IHJlc291cmNlICppcnEsIHZvaWQgKmNvb2tpZSwKIAkJCSAgY29uc3QgY2hhciAqZm10LCAuLi4p OwogaW50CWJ1c19zZXRfcmVzb3VyY2UoZGV2aWNlX3QgZGV2LCBpbnQgdHlwZSwgaW50IHJpZCwK LQkJCSB1X2xvbmcgc3RhcnQsIHVfbG9uZyBjb3VudCk7CisJCQkgYnVzX2FkZHJfdCBzdGFydCwg dV9sb25nIGNvdW50KTsKIGludAlidXNfZ2V0X3Jlc291cmNlKGRldmljZV90IGRldiwgaW50IHR5 cGUsIGludCByaWQsCi0JCQkgdV9sb25nICpzdGFydHAsIHVfbG9uZyAqY291bnRwKTsKLXVfbG9u ZwlidXNfZ2V0X3Jlc291cmNlX3N0YXJ0KGRldmljZV90IGRldiwgaW50IHR5cGUsIGludCByaWQp OworCQkJIGJ1c19hZGRyX3QgKnN0YXJ0cCwgdV9sb25nICpjb3VudHApOworYnVzX2FkZHJfdAli dXNfZ2V0X3Jlc291cmNlX3N0YXJ0KGRldmljZV90IGRldiwgaW50IHR5cGUsIGludCByaWQpOwog dV9sb25nCWJ1c19nZXRfcmVzb3VyY2VfY291bnQoZGV2aWNlX3QgZGV2LCBpbnQgdHlwZSwgaW50 IHJpZCk7CiB2b2lkCWJ1c19kZWxldGVfcmVzb3VyY2UoZGV2aWNlX3QgZGV2LCBpbnQgdHlwZSwg aW50IHJpZCk7CiBpbnQJYnVzX2NoaWxkX3ByZXNlbnQoZGV2aWNlX3QgY2hpbGQpOwpAQCAtNDc0 LDcgKzQ3NSw4IEBACiBzdGF0aWMgX19pbmxpbmUgc3RydWN0IHJlc291cmNlICoKIGJ1c19hbGxv Y19yZXNvdXJjZV9hbnkoZGV2aWNlX3QgZGV2LCBpbnQgdHlwZSwgaW50ICpyaWQsIHVfaW50IGZs YWdzKQogewotCXJldHVybiAoYnVzX2FsbG9jX3Jlc291cmNlKGRldiwgdHlwZSwgcmlkLCAwdWws IH4wdWwsIDEsIGZsYWdzKSk7CisJcmV0dXJuIChidXNfYWxsb2NfcmVzb3VyY2UoZGV2LCB0eXBl LCByaWQsIChidXNfYWRkcl90KTB1bCwKKwkgICAgfihidXNfYWRkcl90KTB1bCwgMSwgZmxhZ3Mp KTsKIH0KIAogLyoKSW5kZXg6IHN5cy9zeXMvcm1hbi5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMv cm1hbi5oCShyZXZpc2lvbiAyODcxODkpCisrKyBzeXMvc3lzL3JtYW4uaAkod29ya2luZyBjb3B5 KQpAQCAtNTQsNiArNTQsOSBAQAogI2RlZmluZQlSRl9BTElHTk1FTlRfTE9HMih4KQkoKHgpIDw8 IFJGX0FMSUdOTUVOVF9TSElGVCkKICNkZWZpbmUJUkZfQUxJR05NRU5UKHgpCQkoKCh4KSAmIFJG X0FMSUdOTUVOVF9NQVNLKSA+PiBSRl9BTElHTk1FTlRfU0hJRlQpCiAKKyNkZWZpbmUgUk1fTUlO X1NUQVJUCSgoYnVzX2FkZHJfdCkwKQorI2RlZmluZSBSTV9NQVhfRU5ECSh+KGJ1c19hZGRyX3Qp MCkKKwogZW51bQlybWFuX3R5cGUgeyBSTUFOX1VOSU5JVCA9IDAsIFJNQU5fR0FVR0UsIFJNQU5f QVJSQVkgfTsKIAogLyoKQEAgLTcwLDggKzczLDggQEAKIAl1aW50cHRyX3QJcl9kZXZpY2U7CQkv KiBkZXZpY2Ugb3duaW5nIHRoaXMgcmVzb3VyY2UgKi8KIAljaGFyCQlyX2Rldm5hbWVbUk1fVEVY VExFTl07CS8qIGRldmljZSBuYW1lIFhYWCBvYnNvbGV0ZSAqLwogCi0JdV9sb25nCQlyX3N0YXJ0 OwkJLyogb2Zmc2V0IGluIHJlc291cmNlIHNwYWNlICovCi0JdV9sb25nCQlyX3NpemU7CQkJLyog c2l6ZSBpbiByZXNvdXJjZSBzcGFjZSAqLworCWJ1c19hZGRyX3QJcl9zdGFydDsJCS8qIG9mZnNl dCBpbiByZXNvdXJjZSBzcGFjZSAqLworCWJ1c19zaXplX3QJcl9zaXplOwkJCS8qIHNpemUgaW4g cmVzb3VyY2Ugc3BhY2UgKi8KIAl1X2ludAkJcl9mbGFnczsJCS8qIFJGXyogZmxhZ3MgKi8KIH07 CiAKQEAgLTc5LDggKzgyLDggQEAKIAl1aW50cHRyX3QJcm1faGFuZGxlOwkJLyogcm1hbiB1bmlx dWlmaWVyICovCiAJY2hhcgkJcm1fZGVzY3JbUk1fVEVYVExFTl07CS8qIHJtYW4gZGVzY3JpcHRp b24gKi8KIAotCXVfbG9uZwkJcm1fc3RhcnQ7CQkvKiBiYXNlIG9mIG1hbmFnZWQgcmVnaW9uICov Ci0JdV9sb25nCQlybV9zaXplOwkJLyogc2l6ZSBvZiBtYW5hZ2VkIHJlZ2lvbiAqLworCWJ1c19h ZGRyX3QJcm1fc3RhcnQ7CQkvKiBiYXNlIG9mIG1hbmFnZWQgcmVnaW9uICovCisJYnVzX3NpemVf dAlybV9zaXplOwkJLyogc2l6ZSBvZiBtYW5hZ2VkIHJlZ2lvbiAqLwogCWVudW0gcm1hbl90eXBl CXJtX3R5cGU7CQkvKiByZWdpb24gdHlwZSAqLwogfTsKIApAQCAtMTA4LDggKzExMSw4IEBACiAJ c3RydWN0CXJlc291cmNlX2hlYWQgCXJtX2xpc3Q7CiAJc3RydWN0CW10eCAqcm1fbXR4OwkvKiBt dXRleCB1c2VkIHRvIHByb3RlY3Qgcm1fbGlzdCAqLwogCVRBSUxRX0VOVFJZKHJtYW4pCXJtX2xp bms7IC8qIGxpbmsgaW4gbGlzdCBvZiBhbGwgcm1hbnMgKi8KLQl1X2xvbmcJcm1fc3RhcnQ7CS8q IGluZGV4IG9mIGdsb2JhbGx5IGZpcnN0IGVudHJ5ICovCi0JdV9sb25nCXJtX2VuZDsJCS8qIGlu ZGV4IG9mIGdsb2JhbGx5IGxhc3QgZW50cnkgKi8KKwlidXNfYWRkcl90CXJtX3N0YXJ0OwkvKiBp bmRleCBvZiBnbG9iYWxseSBmaXJzdCBlbnRyeSAqLworCWJ1c19hZGRyX3QJcm1fZW5kOwkvKiBp bmRleCBvZiBnbG9iYWxseSBsYXN0IGVudHJ5ICovCiAJZW51bQlybWFuX3R5cGUgcm1fdHlwZTsg Lyogd2hhdCB0eXBlIG9mIHJlc291cmNlIHRoaXMgaXMgKi8KIAljb25zdAljaGFyICpybV9kZXNj cjsJLyogdGV4dCBkZXNjcmlwaW9uIG9mIHRoaXMgcmVzb3VyY2UgKi8KIH07CkBAIC0xMTYsMzkg KzExOSwzOSBAQAogVEFJTFFfSEVBRChybWFuX2hlYWQsIHJtYW4pOwogCiBpbnQJcm1hbl9hY3Rp dmF0ZV9yZXNvdXJjZShzdHJ1Y3QgcmVzb3VyY2UgKnIpOwotaW50CXJtYW5fYWRqdXN0X3Jlc291 cmNlKHN0cnVjdCByZXNvdXJjZSAqciwgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kKTsKK2ludAly bWFuX2FkanVzdF9yZXNvdXJjZShzdHJ1Y3QgcmVzb3VyY2UgKnIsIGJ1c19hZGRyX3Qgc3RhcnQs IGJ1c19hZGRyX3QgZW5kKTsKIGludAlybWFuX2F3YWl0X3Jlc291cmNlKHN0cnVjdCByZXNvdXJj ZSAqciwgaW50IHByaSwgaW50IHRpbW8pOwotaW50CXJtYW5fZmlyc3RfZnJlZV9yZWdpb24oc3Ry dWN0IHJtYW4gKnJtLCB1X2xvbmcgKnN0YXJ0LCB1X2xvbmcgKmVuZCk7CitpbnQJcm1hbl9maXJz dF9mcmVlX3JlZ2lvbihzdHJ1Y3Qgcm1hbiAqcm0sIGJ1c19hZGRyX3QgKnN0YXJ0LCBidXNfYWRk cl90ICplbmQpOwogYnVzX3NwYWNlX2hhbmRsZV90IHJtYW5fZ2V0X2J1c2hhbmRsZShzdHJ1Y3Qg cmVzb3VyY2UgKik7CiBidXNfc3BhY2VfdGFnX3Qgcm1hbl9nZXRfYnVzdGFnKHN0cnVjdCByZXNv dXJjZSAqKTsKLXVfbG9uZwlybWFuX2dldF9lbmQoc3RydWN0IHJlc291cmNlICopOworYnVzX2Fk ZHJfdAlybWFuX2dldF9lbmQoc3RydWN0IHJlc291cmNlICopOwogc3RydWN0IGRldmljZSAqcm1h bl9nZXRfZGV2aWNlKHN0cnVjdCByZXNvdXJjZSAqKTsKIHVfaW50CXJtYW5fZ2V0X2ZsYWdzKHN0 cnVjdCByZXNvdXJjZSAqKTsKIGludAlybWFuX2dldF9yaWQoc3RydWN0IHJlc291cmNlICopOwot dV9sb25nCXJtYW5fZ2V0X3NpemUoc3RydWN0IHJlc291cmNlICopOwotdV9sb25nCXJtYW5fZ2V0 X3N0YXJ0KHN0cnVjdCByZXNvdXJjZSAqKTsKK2J1c19zaXplX3QJcm1hbl9nZXRfc2l6ZShzdHJ1 Y3QgcmVzb3VyY2UgKik7CitidXNfYWRkcl90CXJtYW5fZ2V0X3N0YXJ0KHN0cnVjdCByZXNvdXJj ZSAqKTsKIHZvaWQgICAqcm1hbl9nZXRfdmlydHVhbChzdHJ1Y3QgcmVzb3VyY2UgKik7CiBpbnQJ cm1hbl9kZWFjdGl2YXRlX3Jlc291cmNlKHN0cnVjdCByZXNvdXJjZSAqcik7CiBpbnQJcm1hbl9m aW5pKHN0cnVjdCBybWFuICpybSk7CiBpbnQJcm1hbl9pbml0KHN0cnVjdCBybWFuICpybSk7CiBp bnQJcm1hbl9pbml0X2Zyb21fcmVzb3VyY2Uoc3RydWN0IHJtYW4gKnJtLCBzdHJ1Y3QgcmVzb3Vy Y2UgKnIpOwotaW50CXJtYW5fbGFzdF9mcmVlX3JlZ2lvbihzdHJ1Y3Qgcm1hbiAqcm0sIHVfbG9u ZyAqc3RhcnQsIHVfbG9uZyAqZW5kKTsKK2ludAlybWFuX2xhc3RfZnJlZV9yZWdpb24oc3RydWN0 IHJtYW4gKnJtLCBidXNfYWRkcl90ICpzdGFydCwgYnVzX2FkZHJfdCAqZW5kKTsKIHVpbnQzMl90 IHJtYW5fbWFrZV9hbGlnbm1lbnRfZmxhZ3ModWludDMyX3Qgc2l6ZSk7Ci1pbnQJcm1hbl9tYW5h Z2VfcmVnaW9uKHN0cnVjdCBybWFuICpybSwgdV9sb25nIHN0YXJ0LCB1X2xvbmcgZW5kKTsKK2lu dAlybWFuX21hbmFnZV9yZWdpb24oc3RydWN0IHJtYW4gKnJtLCBidXNfYWRkcl90IHN0YXJ0LCBi dXNfYWRkcl90IGVuZCk7CiBpbnQJcm1hbl9pc19yZWdpb25fbWFuYWdlcihzdHJ1Y3QgcmVzb3Vy Y2UgKnIsIHN0cnVjdCBybWFuICpybSk7CiBpbnQJcm1hbl9yZWxlYXNlX3Jlc291cmNlKHN0cnVj dCByZXNvdXJjZSAqcik7Ci1zdHJ1Y3QgcmVzb3VyY2UgKnJtYW5fcmVzZXJ2ZV9yZXNvdXJjZShz dHJ1Y3Qgcm1hbiAqcm0sIHVfbG9uZyBzdGFydCwKLQkJCQkJdV9sb25nIGVuZCwgdV9sb25nIGNv dW50LAorc3RydWN0IHJlc291cmNlICpybWFuX3Jlc2VydmVfcmVzb3VyY2Uoc3RydWN0IHJtYW4g KnJtLCBidXNfYWRkcl90IHN0YXJ0LAorCQkJCQlidXNfYWRkcl90IGVuZCwgdV9sb25nIGNvdW50 LAogCQkJCQl1X2ludCBmbGFncywgc3RydWN0IGRldmljZSAqZGV2KTsKLXN0cnVjdCByZXNvdXJj ZSAqcm1hbl9yZXNlcnZlX3Jlc291cmNlX2JvdW5kKHN0cnVjdCBybWFuICpybSwgdV9sb25nIHN0 YXJ0LAotCQkJCQl1X2xvbmcgZW5kLCB1X2xvbmcgY291bnQsIHVfbG9uZyBib3VuZCwKK3N0cnVj dCByZXNvdXJjZSAqcm1hbl9yZXNlcnZlX3Jlc291cmNlX2JvdW5kKHN0cnVjdCBybWFuICpybSwg YnVzX2FkZHJfdCBzdGFydCwKKwkJCQkJYnVzX2FkZHJfdCBlbmQsIHVfbG9uZyBjb3VudCwgYnVz X2FkZHJfdCBib3VuZCwKIAkJCQkJdV9pbnQgZmxhZ3MsIHN0cnVjdCBkZXZpY2UgKmRldik7CiB2 b2lkCXJtYW5fc2V0X2J1c2hhbmRsZShzdHJ1Y3QgcmVzb3VyY2UgKl9yLCBidXNfc3BhY2VfaGFu ZGxlX3QgX2gpOwogdm9pZAlybWFuX3NldF9idXN0YWcoc3RydWN0IHJlc291cmNlICpfciwgYnVz X3NwYWNlX3RhZ190IF90KTsKIHZvaWQJcm1hbl9zZXRfZGV2aWNlKHN0cnVjdCByZXNvdXJjZSAq X3IsIHN0cnVjdCBkZXZpY2UgKl9kZXYpOwotdm9pZAlybWFuX3NldF9lbmQoc3RydWN0IHJlc291 cmNlICpfciwgdV9sb25nIF9lbmQpOwordm9pZAlybWFuX3NldF9lbmQoc3RydWN0IHJlc291cmNl ICpfciwgYnVzX2FkZHJfdCBfZW5kKTsKIHZvaWQJcm1hbl9zZXRfcmlkKHN0cnVjdCByZXNvdXJj ZSAqX3IsIGludCBfcmlkKTsKLXZvaWQJcm1hbl9zZXRfc3RhcnQoc3RydWN0IHJlc291cmNlICpf ciwgdV9sb25nIF9zdGFydCk7Cit2b2lkCXJtYW5fc2V0X3N0YXJ0KHN0cnVjdCByZXNvdXJjZSAq X3IsIGJ1c19hZGRyX3QgX3N0YXJ0KTsKIHZvaWQJcm1hbl9zZXRfdmlydHVhbChzdHJ1Y3QgcmVz b3VyY2UgKl9yLCB2b2lkICpfdik7CiAKIGV4dGVybglzdHJ1Y3Qgcm1hbl9oZWFkIHJtYW5faGVh ZDsK --001a1141f3be08c46f051e777817-- From owner-freebsd-arch@freebsd.org Sat Aug 29 19:40:18 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 937099C6C7A for ; Sat, 29 Aug 2015 19:40:18 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (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 53A8A1D89; Sat, 29 Aug 2015 19:40:17 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from [10.1.254.15] (cerberus.brkt.com [208.185.168.138]) (authenticated bits=0) by mail.xcllnt.net (8.15.2/8.15.2) with ESMTPSA id t7TJeDC6017566 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Aug 2015 12:40:15 -0700 (PDT) (envelope-from marcel@xcllnt.net) Subject: Re: Devices with 36-bit paddr on 32-bit system Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E03D7F3B-79BE-4559-8E88-38E2B78535BB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Marcel Moolenaar In-Reply-To: Date: Sat, 29 Aug 2015 12:40:07 -0700 Cc: Adrian Chadd , John Baldwin , "freebsd-arch@freebsd.org" Message-Id: <3FD8C08B-5418-4201-ADD1-C636FF1E266F@xcllnt.net> References: <1568331.OrSoeYfXsf@ralph.baldwin.cx> To: Justin Hibbits X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 19:40:18 -0000 --Apple-Mail=_E03D7F3B-79BE-4559-8E88-38E2B78535BB Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On Aug 29, 2015, at 11:35 AM, Justin Hibbits wrote: > > tl;dr I went with using bus_addr_t for the addresses, and kept u_long > for the sizes (I can change it to use bus_size_t instead, but it's > already vm_offset_t on PowerPC, which is long anyway). Unfortunately, you want to change count from u_long to something wider as well. If you have more than 4GB of memory and want a resource for it, you have start=0, end>4GB and count>4GB for the entire range. -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_E03D7F3B-79BE-4559-8E88-38E2B78535BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV4gqYAAoJEIda8t8f0tjjsZMQAM4RoqhBy1BxUHo5u1EQri+o DpTaxZBmdetmkiFqeePiFg/NjSJZ6zm37qROmLttgW6OovZyYShNY6rObg4KmRh2 TGMuJDNyB6RqU5T5N7ZOgiY2tag9AH3dA/ZqSgP02VJJAGAwiAXT1Ltm7l69I1KO Jbc1scYhO1qLtKhrcjNaTWjhEK/Zf4kXl/Iubd708zHQvGLcsfp2UM+t/4OQIx5b zgy0lMbxBBMlXlSLBvaVL/pzKdoZK5pPIdkI1iXpxBBSNUn/Ft7uKusJ9uqcc3pF xCAaKvv+39Qtck+Qo2H+5umkdzwpz1F1r7MycllvqKzNKQTqL3h0Fx9rKqqzO8GS 6GUvROZ7kCiEZyygwjQCHPh3qWKht79y2W2FCg2DeiqCHlawJdNtXlhSeJQa+44u 3NlikkdqdaHHyErPMXjQE3X7IiVKglIPMFVkdklWgnG/XUWS3apfDRlomMg8SiyZ fkdW/IzxzWkB48qF2WOnPbYQkzW8/ZInZWxZzsGb/SAhaPB9nxqfcjgMPP4qhUkB 7ptlSfNUIYEl/lo4vvwZWprJZDkXrW/OM7NvFZFykmj0rRZ1Yn3xnlZUb8tfjBwq QhrQMgtt1jQrzQTVg09nYHYiI39fxQrkRmCD0Ich5QpnWwrFHCBThPI067WBZ28m MXf/RN5xkvCV8A1KuHrL =mVcC -----END PGP SIGNATURE----- --Apple-Mail=_E03D7F3B-79BE-4559-8E88-38E2B78535BB--