> 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
