Branch: refs/heads/master
Home: https://github.com/tianocore/edk2
Commit: b917a5b7b3e2332b223f18f13c4ec24e14800962
https://github.com/tianocore/edk2/commit/b917a5b7b3e2332b223f18f13c4ec24e14800962
Author: Pohan Wu <poh...@qti.qualcomm.com>
Date: 2025-04-16 (Wed, 16 Apr 2025)
Changed paths:
M MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBot.c
Log Message:
-----------
MdeModulePkg/UsbMassStorageDxe: Remove Port Reset
During USB mass storage enumeration, if a USB transfer fails due to any
other reason, UsbMassStorageDxe will attempt to reset the device.
With the commit ed07a2bb11 ("MdeModulePkg/UsbBusDxe: USB issue fix when
the port reset"), UsbIoPortReset now tears down the USB device context
and reinstalls it (via DisconnectController & ConnectController).
This process is not handled by the UsbMassDriver, causing the upper
layer to access an old pointer that has been freed during the teardown,
leading to a crash.
Example:
UsbMassReadBlocks (Failed)
-> UsbMassReset
-> UsbBotResetDevice
-> UsbIoPortReset (teardown + reinstall and return)
Now the UsbBot context pointer is invalidated and pointing to freed
memory.
-> UsbBot->UsbIo->UsbControlTransfer() therefore accesses a invalid
pointer and crashes.
The fix is to ignore the ExtendedVerification, which is supposed to
perform a more exhaustive verification operation during the reset. In
MassStorageDxe, ExtendedVerification perform the parent port reset
(UsbIoPortReset). Ultimately, the MassStorage device should not reset
the parent port due to a transfer error. By not performing any extended
verification, the teardown is prevented, thereby avoiding the crash.
Signed-off-by: Jack Pham <ja...@qti.qualcomm.com>
Commit: 948d4ba0be6352d41e8b25895a10f51b5ee7b928
https://github.com/tianocore/edk2/commit/948d4ba0be6352d41e8b25895a10f51b5ee7b928
Author: Pohan Wu <poh...@qti.qualcomm.com>
Date: 2025-04-16 (Wed, 16 Apr 2025)
Changed paths:
M MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c
Log Message:
-----------
MdeModulePkg/UsbMassStorageDxe: Remove excessive logging
When a USB mass storage device is not ready (e.g., still powering up
or the hard disk has not reached the desired RPM), the ExecCommand
function fails.This failure is not a true error. Logging it as
DEBUG_ERROR will generate logs for properly functioning devices as
well, potentially flooding logs for older devices.
As mentioned in the command, proper error information retrieval
should occur in the sense request. The solution is to downgrade
the log level from DEBUG_ERROR to DEBUG_INFO.
Signed-off-by: Jack Pham <ja...@qti.qualcomm.com>
Compare: https://github.com/tianocore/edk2/compare/0f1c0d2d2d9e...948d4ba0be63
To unsubscribe from these emails, change your notification settings at
https://github.com/tianocore/edk2/settings/notifications
_______________________________________________
edk2-commits mailing list
edk2-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-commits
