- When trying to find a device, don't fail with STATUS_NOT_FOUND if no
associated symbolic links are present. Instead, that test was wrong,
and should go out of the search loop to do the drive-letter processing.
Addendum to commit f9f5a78715.
- In addition, when using the associated-device method, fix the list
used to retrieve the corresponding device.
- In the TryWithVolumeName: block, reset DeviceString to NULL after
freeing, so that we can correctly fail with STATUS_NOT_FOUND if no
suitable device was found, before initializing the output data.
- Use FIELD_OFFSET to correct structure and member instead of hardcoding
sizeof-s of fields until the member of interest.
- Fix a bug in MountMgrQueryDosVolumePath() where the FIELD_OFFSET used
in the entry structure size validation was incorrect.
FIELD_OFFSET(MOUNTMGR_TARGET_NAME, DeviceNameLength) is == 0 since
DeviceNameLength is the first member of the MOUNTMGR_TARGET_NAME
structure. The intended member was DeviceName.
Addendum to commit f9f5a78715.
- Declare CMBATT_DISCHARGE_TIME and CMBATT_CAPACITY_BOGUS constructs
- Determine if the battery was already discharging and if not, update the time when it's being discharged
- Fix the condition where it checks if the battery has been discharging for quite some time
- Default the time to BATTERY_UNKNOWN_TIME if querying the estimated battery time request fails or if the battery has just started discharging not over 15 seconds
CORE-18969
CORE-19452
IoInitializeRemoveLock expects an allocation tag to be provided when it allocates debug data in the kernel.
Passing 0 leads to a bunch of ASSERTs in the kernel as such data is allocated by ExAllocatePoolWithTag of which a tag has to be supplied, it's not optional.
- Introduce some new constructs
- Annotate the function prototypes with SAL2
- Re-structure & remove some useless fields in COMPBATT_DEVICE_EXTENSION and COMPBATT_BATTERY_DATA
- PartMgrAddDevice(): If IoAttachDeviceToDeviceStack() fails, bail out
immediately, instead of continuing initializing the device extension
then deciding to fail.
- PartitionCreateDevice(): Initialize the fields pertaining to parent
device linking in the partition device extension, before the other fields
(following in a similar way what's done in PartMgrAddDevice).
_BIX is basically _BIF but with more information added, such as cycle count, measurement capacity accuracy and whatnot.
Starting with ACPI 4.0 _BIF is rendered obsolete and as a matter of fact a lot of modern hardware fill their ACPI machine data to _BIX.
ReactOS must go forward and beyond, compatibility with _BIF is kept. NOTE that a machine can ONLY support one battery static information method!
CORE-18969
CORE-19452
BatteryClassStatusNotify is used by battery miniport drivers to notify the Battery Class of a status change. This can either be a battery status change or battery tag assignation, depending on what the device extension (namely the composite battery) waits for.
We do have implementation for EVENT_BATTERY_STATUS but not for EVENT_BATTERY_TAG. What happens is when BatteryClassIoctl fails to query the battery tag because it has not yet been assigned, the thread is stuck on waiting for the event object to be signaled, forever.
This tipically happens when a timeout of -1 (meaning the calling thread must wait indefinitely) is supplied. The composite battery driver (COMPBATT) is responsible to signal the Battery Class when a CM (Control Method) ACPI battery receives a tag, which then this function will signal the event.
CORE-18969
CORE-19452
ReactOS (like any other OSes) expects power data to be represented in milliwatts per hour, not in milliamps per hour.
Currently CMBATT defaults the stats to unknown values, if that's the case, and there are a bunch of machines that do report their data from _BIF ACPI method in ampere.
CORE-18969
CORE-19452
KeWaitForSingleObject takes 100ns unit for timeout. Both IOCTL_BATTERY_QUERY_TAG and IOCTL_BATTERY_QUERY_STATUS take a wait for the timeout in milliseconds.
Supposedly a miniport driver wants to supply a wait of 5000 ms (which is equivalent to 5 s), the miniport driver WON'T BE WAITING 5 seconds but 0.5!!!
CORE-18969
CORE-19452
See https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-rtlqueryregistryvalues
The RTL_REGISTRY_OPTIONAL applies to the first parameter of the
RtlQueryRegistryValues() function, not to the Flags member of the
table entries. However, a RTL_QUERY_REGISTRY_REQUIRED flag exists
to mark values whose existence is NOT optional.
Problematic usage was introduced in the following modules:
drivers/input/i8042prt: Commit e7e959fb0 (r30000)
drivers/input/kbdclass: Commit 5a77f871d (r18911)
drivers/input/mouclass: Commit aeeab7d1f (r18906)
drivers/input/sermouse: Commit 3f348259c (r19100)
rosapps/drivers/green : Commit c8a90f769 (r21165)
Rename the Ext2 recognizer to a more generic Ext to be more future-proof with a possible upcoming ext4 support.
Also, it already makes no sense to use the name ext2 as it already recognizes all the FS of the "Ext family".
In addition, add the Ext Recognizer for CDs.
They were reversed, which meant to immediately complete the IRP
if conditions were NOT satisfied.
Remove a now useless/invalid call to QueryStatus, to return the
status which lead to IRP completion.
During investigation into some of the USB stack issues we've been running into I've found that when a USB storage device is already plugged in during boot and removed before it finishes initialization we run into this assert.
The logic in this function removes the pools made for the following entries in DeviceExtension indiscriminately this makes debugging a bit more difficult. Instead of depending on this behavior of ALWAYS being filled with valid data, let's free the following pools ONLY if they're initialized. This change prevents us from bugchecking when USB flash drives are removed early during boot. This makes the debugging experience a little more sane.
