On 08/19/16 04:57, Zeng, Star wrote: > On 2016/8/19 10:45, Zeng, Star wrote: >> On 2016/8/19 10:26, Laszlo Ersek wrote: >>> On 08/19/16 04:00, Fan, Jeff wrote: >>>> Laszlo, >>>> >>>> I could revert this patch firstly. >>> >>> Thank you, that would be very kind. >>> >>>> Could you please dig out the OVMF to address the potential issue, >>>> then I could re-commit it for those platforms required this patch. >>> >>> The problem is that this week (what remains of it) and the next week I >>> won't really have time for this -- tomorrow I'm hoping to finish up >>> something else in a mortal hurry. It was actually in preparation for >>> rebasing / pushing that work that I pulled "master", and found out about >>> the regression. >>> >>> Can we perhaps get help from the variable stack maintainers? What's the >>> design of the (lack of) depexes on those drivers? >> >> Variable driver consumes >> PcdFlashNvStorageVariableBase(64)/PcdFlashNvStorageVariableSize to >> produce *gEfiVariableArchProtocolGuid* protocol. >> Variable driver registers (SMM)FTW protocol notification function >> SmmFtwNotificationEvent() or FtwNotificationEvent() to produce >> *gEfiVariableWriteArchProtocolGuid* protocol. >> (SMM)FTW driver has dependency on gEfiSmmFirmwareVolumeBlockProtocolGuid >> or gEfiFirmwareVolumeBlockProtocolGuid. >> >> I am not so sure what you said about the (lack of) depexes on those >> drivers. >> >> Did you see variable driver loaded and started when ASSERT appeared on >> OVMF? > > > You may could compare the serial logs to get if there is some driver > execution flow differences for the images built without and with this > patch.
Thanks, I'll try to do that the week after next or so, hopefully. Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
