From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=67.231.154.164; helo=dispatch1-us1.ppe-hosted.com; envelope-from=tpilar@solarflare.com; receiver=edk2-devel@lists.01.org Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4F49021959CB2 for ; Thu, 24 Jan 2019 04:58:38 -0800 (PST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 0ABF7B80057; Thu, 24 Jan 2019 12:58:37 +0000 (UTC) Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 24 Jan 2019 04:58:33 -0800 To: Laszlo Ersek CC: "edk2-devel@lists.01.org" References: <6029fb15-3820-0f05-f02a-577e99592bbc@solarflare.com> <32137552-e2b0-4392-17c7-dedaa1f05244@redhat.com> <09017041-d418-1186-9942-dfa70d82c4d6@solarflare.com> <67f8fb4a-5e1b-8bbc-90d4-670ff7e3bfe8@redhat.com> <5185c0b2-031f-ec50-b273-2665d83ef38a@solarflare.com> From: "Tomas Pilar (tpilar)" Message-ID: <923ebd9f-ef26-c96d-37cc-5cc76f88fea1@solarflare.com> Date: Thu, 24 Jan 2019 12:58:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.17.20.51] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24386.005 X-TM-AS-Result: No-12.510700-4.000000-10 X-TMASE-MatchedRID: QfHZjzml1E84HKI/yaqRmzPDkSOzeDWWTI0NfY99MMmynk7TnYzMuhoJ Ww+GnpANp0k3jQHU8uy14PqAkOSy5HwvP2dtBRFihsE+u3nnCfDPWW4KILxvBG7gWSfKrKyEzsr SpkdrfT7Y0FxaE6bZtVqeKfkwp9lKleL2V5YMXulIRA38P/dwbiFq4bKNOR/1MKZRiezcUtNg5U IGiwIN9dWYT4U+OhPNhI17TlshUTSeDyjE0GkBlGzBijri5+RVt+hhn8Iy6GWbKItl61J/ycnjL TA/UDoAoTCA5Efyn8CNo+PRbWqfRMprJP8FBOIa5NMuXlwW3WotW6/Oc6G4fuOgHYY1279VjN53 iOvLtPR82iPqMdwzZA== X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--12.510700-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24386.005 X-MDID: 1548334717-L7UEhWbYGme9 Subject: Re: Network Stack Budgeting X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2019 12:58:38 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US > This reeks. :) > > It looks like some driver in the platform sets up a protocol notify > callback for SNP, with gBS->CreateEvent() + > gBS->RegisterProtocolNotify(). Your driver's DriverBindingStart() > function is called normally from BDS, via ConnectController(). In > DriverBindingStart(), you install an SNP instance, which signals the > event (makes it pending / queues the notification function for it). Once > you drop the TPL again, the notification function is called, on the > stack of gBS->RestoreTPL(). > > The event's notification funciton probably uses the "Registration" > feature of gBS->RegisterProtocolNotify(), together with > gBS->LocateProtocol(), to process only those SNP instances that it > hasn't seen yet. In other words, it catches exactly the SNP instance > that your driver just produced, and then it calls the Start() member of it. This was my assumption a well. I did not consider that another third party driver could be the cause of this. > I've now run > > git grep -A10 -B10 -w gEfiSimpleNetworkProtocolGuid > > on edk2, and then searched the output for "RegisterProtocolNotify". > There were no hits. So, I don't think anything in edk2 behaves like > described above (thankfully!). That's good to know, I was going to have a browse through the edk2 network stack but this is reassuring. > > You mentioned seeing this on "DELL 13G platforms". I suggest opening a > support case with Dell. The problem is much more widespread than that. This log is from a HP gen 10 server. I am pretty sure the DELL 14G also has the same behaviour. That's what originally led me to think it might be in upstream. Cheers, Tom