Date   

Re: when bug 2002 will be fixed

wenyi,xie
 

Hi Zhiguang,

I see. Thank you for your reply.

Regards
Wenyi

On 2020/9/16 17:03, Liu, Zhiguang wrote:
Hi Wenyi,

I have sent patch for review and get some comments.
https://edk2.groups.io/g/devel/message/61324
And I still need some time to enhance this patch.

Thanks
Zhiguang

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
wenyi,xie via groups.io
Sent: Wednesday, September 16, 2020 4:55 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] when bug 2002 will be fixed

Hi, all
May I ask when bug 2002 will be fixed, what's the status now?
Bug 2002 SMM pointer leak in SmmVariableGetStatistics()
https://bugzilla.tianocore.org/show_bug.cgi?id=2002




Re: when bug 2002 will be fixed

Zhiguang Liu
 

Hi Wenyi,

I have sent patch for review and get some comments.
https://edk2.groups.io/g/devel/message/61324
And I still need some time to enhance this patch.

Thanks
Zhiguang

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
wenyi,xie via groups.io
Sent: Wednesday, September 16, 2020 4:55 PM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] when bug 2002 will be fixed

Hi, all
May I ask when bug 2002 will be fixed, what's the status now?
Bug 2002 SMM pointer leak in SmmVariableGetStatistics()
https://bugzilla.tianocore.org/show_bug.cgi?id=2002




when bug 2002 will be fixed

wenyi,xie
 

Hi, all
May I ask when bug 2002 will be fixed, what's the status now?
Bug 2002 SMM pointer leak in SmmVariableGetStatistics()
https://bugzilla.tianocore.org/show_bug.cgi?id=2002


Re: Is it valid to use DEC_VERSION instead of DEC_SPECIFICATION in dec file

wenyi,xie
 

Hi, Laszlo,

Thank you for your confirming, I will send a patch soon.

Regards
Wenyi

On 2020/9/10 20:59, Laszlo Ersek wrote:
On 09/10/20 09:27, wenyi,xie via groups.io wrote:
I found DEC_VERSION is used in [Defines] section in EmulatorPkg.dec, but I checked the code in BaseTools and found DEC_VERSION can't be parsed.
Right, the edk2 DEC specification document only knows about
DEC_SPECIFICATION too. Please file a bug, or send a patch, for
"EmulatorPkg.dec".

Thanks,
Laszlo


Re: Is it valid to use DEC_VERSION instead of DEC_SPECIFICATION in dec file

Laszlo Ersek
 

On 09/10/20 09:27, wenyi,xie via groups.io wrote:
I found DEC_VERSION is used in [Defines] section in EmulatorPkg.dec, but I checked the code in BaseTools and found DEC_VERSION can't be parsed.
Right, the edk2 DEC specification document only knows about
DEC_SPECIFICATION too. Please file a bug, or send a patch, for
"EmulatorPkg.dec".

Thanks,
Laszlo


Is it valid to use DEC_VERSION instead of DEC_SPECIFICATION in dec file

wenyi,xie
 

I found DEC_VERSION is used in [Defines] section in EmulatorPkg.dec, but I checked the code in BaseTools and found DEC_VERSION can't be parsed.


Re: loop in CoreCheckTimers

Stanley Gan
 

Hi Laszlo,
Thanks for your reply.
I mean " CoreSignalEvent (mEfiCheckTimerEvent)" in CoreCheckTimers is not
necessary.
Because all timer event already signified in CoreCheckTimers 1st run. We
don't need to run CoreCheckTimers again.
I actually add Commit 239b50a86370 to my project. It can solve my problem.
But I don't think it's a good long term solution. It's not the root cause
of the issue.

On Mon, Sep 7, 2020 at 7:39 PM Laszlo Ersek <lersek@redhat.com> wrote:

(CC Jeff)

On 09/07/20 02:29, Stanley Gan wrote:
Hi All,



I have some questions about MdeModulePkg\Core\Dxe\Event\Timer.c
CoreCheckTimers.

My system will keep looping in CoreCheckTimers in some scenarios:

· CPU run very slow (Cache disabled)

· A lot of timer event (Network stack enabled)

In normal boot, CoreCheckTimers will execute two times. 1st time, it
actually signifies timer event. 2nd time, because there is no expired
timer, it will exit quickly.

In my scenario, another time interrupt comes and updates EfiSystemTime at
second CoreCheckTimers. The system will keep looping in CoreCheckTimers.

My questions are:

1. Is the red line below necessary?
What do you mean by "red line"?

Can we disable interrupt at TPL
30?

//

// If that's before now, then reset the timer to start from now

//

if (Event->Timer.TriggerTime <= SystemTime) {

Event->Timer.TriggerTime = SystemTime;

CoreSignalEvent (mEfiCheckTimerEvent);

}

2. If the system runs slowly, do we need to expand the timer
interrupt interval? Is there any golden standard about the ratio between
CPU speed and timer interval?
Perhaps related: commit 239b50a86370 ("OvmfPkg: End timer interrupt
later to avoid stack overflow under load", 2020-06-18).

Thanks,
Laszlo


Re: loop in CoreCheckTimers

Laszlo Ersek
 

(CC Jeff)

On 09/07/20 02:29, Stanley Gan wrote:
Hi All,



I have some questions about MdeModulePkg\Core\Dxe\Event\Timer.c
CoreCheckTimers.

My system will keep looping in CoreCheckTimers in some scenarios:

· CPU run very slow (Cache disabled)

· A lot of timer event (Network stack enabled)

In normal boot, CoreCheckTimers will execute two times. 1st time, it
actually signifies timer event. 2nd time, because there is no expired
timer, it will exit quickly.

In my scenario, another time interrupt comes and updates EfiSystemTime at
second CoreCheckTimers. The system will keep looping in CoreCheckTimers.

My questions are:

1. Is the red line below necessary?
What do you mean by "red line"?

Can we disable interrupt at TPL
30?

//

// If that's before now, then reset the timer to start from now

//

if (Event->Timer.TriggerTime <= SystemTime) {

Event->Timer.TriggerTime = SystemTime;

CoreSignalEvent (mEfiCheckTimerEvent);

}

2. If the system runs slowly, do we need to expand the timer
interrupt interval? Is there any golden standard about the ratio between
CPU speed and timer interval?
Perhaps related: commit 239b50a86370 ("OvmfPkg: End timer interrupt
later to avoid stack overflow under load", 2020-06-18).

Thanks,
Laszlo


loop in CoreCheckTimers

Stanley Gan
 

Hi All,



I have some questions about MdeModulePkg\Core\Dxe\Event\Timer.c
CoreCheckTimers.

My system will keep looping in CoreCheckTimers in some scenarios:

· CPU run very slow (Cache disabled)

· A lot of timer event (Network stack enabled)

In normal boot, CoreCheckTimers will execute two times. 1st time, it
actually signifies timer event. 2nd time, because there is no expired
timer, it will exit quickly.

In my scenario, another time interrupt comes and updates EfiSystemTime at
second CoreCheckTimers. The system will keep looping in CoreCheckTimers.

My questions are:

1. Is the red line below necessary? Can we disable interrupt at TPL
30?

//

// If that's before now, then reset the timer to start from now

//

if (Event->Timer.TriggerTime <= SystemTime) {

Event->Timer.TriggerTime = SystemTime;

CoreSignalEvent (mEfiCheckTimerEvent);

}

2. If the system runs slowly, do we need to expand the timer
interrupt interval? Is there any golden standard about the ratio between
CPU speed and timer interval?


Re: THe driver image handle

Laszlo Ersek
 

On 09/04/20 13:04, Tomas Pilar (tpilar) wrote:
Hi Libo,

The convention says that when a driver manages a device, it should find the
relevant IO protocol installed on the device handle (for example a PCI
device will have EFI_PCI_IO_PROTOCOL) and open it using
the EFI_OPEN_PROTOCOL_BY_DRIVER attribute. The driver will keep the
protocol open for the entire duration while it manages the device. You can
use boot services (UefiBootServicesTableLib.h), in particular the
gBS->OpenProtocolInformation() function, to inspect who has a specific
protocol on a specific handle open and with what attributes.

Now, if you are a user and you boot into UEFI shell, all you have to do is
inspect the (shell) handle using the 'dh -d -v <handle>' command.
See also the EfiTestManagedDevice() and EfiTestChildHandle() utility
functions in UefiLib.

Thanks
Laszlo


Re: THe driver image handle

Tomas Pilar (tpilar)
 

Hi Libo,

The convention says that when a driver manages a device, it should find the
relevant IO protocol installed on the device handle (for example a PCI
device will have EFI_PCI_IO_PROTOCOL) and open it using
the EFI_OPEN_PROTOCOL_BY_DRIVER attribute. The driver will keep the
protocol open for the entire duration while it manages the device. You can
use boot services (UefiBootServicesTableLib.h), in particular the
gBS->OpenProtocolInformation() function, to inspect who has a specific
protocol on a specific handle open and with what attributes.

Now, if you are a user and you boot into UEFI shell, all you have to do is
inspect the (shell) handle using the 'dh -d -v <handle>' command.

Cheers,
Tom

On Fri, Sep 4, 2020 at 2:43 AM Feng Libo <lbfeng@zd-tech.com.cn> wrote:

Hello, Madam/Sir,


I have a problem:


Given a device handle, How to find the driver image handles that are
managing the controller? The drivers are compliant to the UEFI driver model.


Thanks


--

Best Regards


Feng Libo
ZD Technology (Beijing) Co., Ltd



THe driver image handle

Feng Libo <lbfeng@...>
 

Hello, Madam/Sir,


I have a problem:


Given a device handle, How to find the driver image handles that are managing the controller? The drivers are compliant to the UEFI driver model.


Thanks


--

Best Regards


Feng Libo
ZD Technology (Beijing) Co., Ltd


Re: How to set PcdEmuVariableNvModeEnable

wenyi,xie
 

Hi, Laszlo and Ard,

Thank you for your detailed instruction. It's clear to me now.

Thanks
Wenyi

On 2020/9/2 15:57, Ard Biesheuvel wrote:
On 9/2/20 9:52 AM, Laszlo Ersek wrote:
On 09/02/20 05:35, wenyi,xie via groups.io wrote:
InitEmuNonVolatileVariableStore or InitRealNonVolatileVariableStore
will be used to initial non-volatile variable according to value of
PcdEmuVariableNvModeEnable.
How do I know which one I should use?
The DEC file says:

   ## Indicates if Variable driver will enable emulated variable NV mode.<BR><BR>
   #  If this PCD is configured to dynamic, its value should be set before Variable driver starts to work,<BR>
   #  otherwise default value will take effect.<BR>
   #   TRUE  - An EMU variable NV storage will be allocated or reserved for NV variables.<BR>
   #   FALSE - No EMU variable NV storage will be allocated or reserved for NV variables.<BR>
   # @Prompt EMU variable NV mode enable.
   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|FALSE|BOOLEAN|0x01100001

After some brief checks, the default FALSE value means that you have a
flash chip for storing non-volatile variables, a platform driver that
exposes the FVB (Firmware Volume Block) protocol on top of the flash
chip, and your platform includes the universal FTW (fault tolerant
write) protocol / driver on top of FVB. Whereas TRUE means that the
non-volatile storage will be emulated in runtime data type memory.

So, if your platform has a flash chip or other permanent storage you can
use for storing non-volatile UEFI variables, and you are able to provide
an FVB driver for that storage in your platform firmware, then stick
with the default FALSE value (and include the FTW driver too in your DSC
/ FDF files).

(CC'ing Ard because ArmVirtXen uses

   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|TRUE
)
Thanks for the CC.

To clarify the Xen situation: we never got around to implementing this properly for Xen; Xen relies heavily on paravirtualization, and so it would make little sense to implement NOR flash emulation - instead, something modeled after the [S]MM variable runtime DXE would make much more sense, where the get/set variable calls are simply relayed to another execution context (which would be dom0 user space in the case of Xen, I presume)

Until such a driver materializes, we are stuck with the current emulated varstore support, which loses its memory at a reboot.


.


Re: How to set PcdEmuVariableNvModeEnable

Laszlo Ersek
 

On 09/02/20 05:35, wenyi,xie via groups.io wrote:
InitEmuNonVolatileVariableStore or InitRealNonVolatileVariableStore
will be used to initial non-volatile variable according to value of
PcdEmuVariableNvModeEnable.
How do I know which one I should use?
The DEC file says:

## Indicates if Variable driver will enable emulated variable NV mode.<BR><BR>
# If this PCD is configured to dynamic, its value should be set before Variable driver starts to work,<BR>
# otherwise default value will take effect.<BR>
# TRUE - An EMU variable NV storage will be allocated or reserved for NV variables.<BR>
# FALSE - No EMU variable NV storage will be allocated or reserved for NV variables.<BR>
# @Prompt EMU variable NV mode enable.
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|FALSE|BOOLEAN|0x01100001

After some brief checks, the default FALSE value means that you have a
flash chip for storing non-volatile variables, a platform driver that
exposes the FVB (Firmware Volume Block) protocol on top of the flash
chip, and your platform includes the universal FTW (fault tolerant
write) protocol / driver on top of FVB. Whereas TRUE means that the
non-volatile storage will be emulated in runtime data type memory.

So, if your platform has a flash chip or other permanent storage you can
use for storing non-volatile UEFI variables, and you are able to provide
an FVB driver for that storage in your platform firmware, then stick
with the default FALSE value (and include the FTW driver too in your DSC
/ FDF files).

(CC'ing Ard because ArmVirtXen uses

gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable|TRUE
)

Thanks,
Laszlo


How to set PcdEmuVariableNvModeEnable

wenyi,xie
 

InitEmuNonVolatileVariableStore or InitRealNonVolatileVariableStore will be used to initial non-volatile variable according to value of PcdEmuVariableNvModeEnable.
How do I know which one I should use?


Re: System hangs with 'Type 2: Sev:80; Class:3 SubClass:D; Op:6' error at boot-up

Andrew Fish <afish@...>
 



On Aug 28, 2020, at 9:02 AM, Laszlo Ersek <lersek@...> wrote:

On 08/28/20 12:04, udai sharma wrote:
Hi Team,

I am seeing this error on my serial console coming from Oprom boot driver. 

I am unable to find/debug from where it is getting originated and what could be root cause for it.



ERROR: Type:2; Severity:80; Class:3; Subclass:D; Operation: 6



From Google, I could decode it as:

TYPE: 2 = Error Code



SEVERITY: For Error Code:

0x80 = Major



CLASS: 0x03 = Software



SUBCLASS: For Software:

0x0D = X86 Exception



Here, I am not sure what Operation:6 corresponds to.



That sounds like an x86 exception vector number. 6 is an Invalid Opcode, and in EFI that usually means the code ran off into the weeds and started executing garbage. So stack corruption, or bad pointers. 

Thanks,

Andrew Fish



One more thing I have noticed is that same Oprom image when loaded from shell using "loadpcirom" works 

fine but if I update it into the flash memory of the adapter and BIOS reads it during boot-up, it hangs 

with above mentioned ERROR code.



Contact your card / adapter vendor, is the best guess I have...

Laszlo


System hangs with 'Type 2: Sev:80; Class:3 SubClass:D; Op:6' error at boot-up

udai sharma <udai16787@...>
 

Hi Team,
I am seeing this error on my serial console coming from Oprom boot driver.
I am unable to find/debug from where it is getting originated and what could be root cause for it.

ERROR: Type:2; Severity:80; Class:3; Subclass:D; Operation: 6

From Google, I could decode it as:
TYPE: 2 = Error Code

SEVERITY: For Error Code:
0x80 = Major

CLASS: 0x03 = Software

SUBCLASS: For Software:
0x0D = X86 Exception

Here, I am not sure what Operation:6 corresponds to.

One more thing I have noticed is that same Oprom image when loaded from shell using "loadpcirom" works
fine but if I update it into the flash memory of the adapter and BIOS reads it during boot-up, it hangs
with above mentioned ERROR code.

Need help.

Thanks in advance.


Re: System hangs with 'Type 2: Sev:80; Class:3 SubClass:D; Op:6' error at boot-up

Laszlo Ersek
 

On 08/28/20 12:04, udai sharma wrote:
Hi Team,

I am seeing this error on my serial console coming from Oprom boot driver.

I am unable to find/debug from where it is getting originated and what could be root cause for it.



ERROR: Type:2; Severity:80; Class:3; Subclass:D; Operation: 6



From Google, I could decode it as:

TYPE: 2 = Error Code



SEVERITY: For Error Code:

0x80 = Major



CLASS: 0x03 = Software



SUBCLASS: For Software:

0x0D = X86 Exception



Here, I am not sure what Operation:6 corresponds to.



One more thing I have noticed is that same Oprom image when loaded from shell using "loadpcirom" works

fine but if I update it into the flash memory of the adapter and BIOS reads it during boot-up, it hangs

with above mentioned ERROR code.

Contact your card / adapter vendor, is the best guess I have...

Laszlo


Re: ESRT in OVMF

Sandeep Dhanvada
 

Hi Tom,

I am using OVMF.
I will try to enable some debug info from DxeCapsuleLib.

Thanks,
Sandeep


ESRT in OVMF

Tomas Pilar (tpilar)
 

Hi Sandeep,

Remind me, are you using a real platform to do these tests or are you using
OVMF? If you are using real hardware, the platform needs to properly
support capsules, which is quite rare unless you are working on something
that's cutting edge. On OVMF you can modify the DxeCapsuleLib to be more
verbose.

In other words, if CapsuleApp.efi does not work, the ESRT way of upding the
driver will not work since they use the same mechanism.

Cheers,
Tom


On Tue, Aug 18, 2020 at 6:40 AM Sandeep Dhanvada <
sandeep.dhanvada@xilinx.com> wrote:

Hi Tom,

Sorry for the delayed response. I was offloaded to some other work.

Thanks for the pointer. There was some issue in FMP code in UEFI driver.
After fixing this issue, booting is fine and ESRT entry is also generated
by BIOS.

CapsuleApp.efi with embedded FMP driver capsule is giving error that "Not
Ready", but, a capsule without embedded driver was fine. I see that next
boot is recognizing the capsule, but, it is not updated. I added AsciiPrint
in SetImage and GetImageInfo functions, but, i see only prints in
GetImageInfo, but not from SetImage. and there is no debug information from
BIOS environment that capsule update failed. Is there any way we can add
debug information in BIOS?

Thanks,
Sandeep



501 - 520 of 862