The revision 1 structure should have 21 items, but on my laptop, it doesn't.
That's fine, we can parse it as if it was a revision 0 structure. This way I
can see the battery status on my machine.
Change-Id: I743173e05318d686049454983e378a08c0a1980a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5155
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I1f42447e537ea7522ac299f028d530beb5067350
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5142
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
see Devicetree Specification,
section 2.3.5 #address-cells and #size-cells
The #address-cells and #size-cells properties may be used in any
device node that has children in the devicetree hierarchy and
describes how child device nodes should be addressed.
The #address-cells and #size-cells properties are not inherited from
ancestors in the devicetree. They shall be explicitly defined.
If missing, a client program should assume a default value of 2
for #address-cells, and a value of 1 for #size-cells.
Change-Id: Iafed49358540f8ac7aa673c3dc0191c9b580250b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5144
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
That's right kids, std::remove doesn't (and can't) actually remove
things from containers! Instead you have to pass its results into
container::erase in order to do anything at all.
Fixes#17579, and in my testing at least, the strange crashes
and heap corruptions.
Includes support for new I219 device families.
Taken from the 13.1 releng branch (currently on "beta 2" status.)
Tested in QEMU and VMware. The "e1000" device works OK in QEMU,
"e1000e" does not anymore, but reportedly the FreeBSD devs say
it does on bare metal, so this is probably a QEMU bug (it doesn't
seem to be a commonly used device.)
This reverts commit 8497a2cc28.
The VFS layer is not at all ready for this. Many places in the
code implicitly assume ino_t values will never change. This
functionality is only necessary for live shrinking of partitions,
which is a feature niche enough we do not need to worry about
implementing it in the first round of resizing (if ever.)
This is a bit excessive: a file with a B_MINI_ICON resource of the wrong
size should not result in crashing Tracker, the resource should simply
be ignored.
Fixes#17668.
Change-Id: I55a210eb829e568d254d8ab569720145c0ea5a09
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5115
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
we check the OpRegion version and use the rvda pointer when available.
from 2.1 the pointer is relative.
Change-Id: I64d8aea65368aa3c5597f63a2b96b6a430e04315
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5109
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* solves #17659
* We assigned the volume label to the root, but not the boot
sector (partition boot sector, not MBR)
Change-Id: I9c53204c18709c2d225cc8ea338290aa89d42083
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5106
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Obtain the size of local package files.
Fixes#17445
Change-Id: Ica15d3f7c1e80bcf9b3b23d6af851cc33b5b6253
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5016
Reviewed-by: Andrew Lindesay <apl@lindesay.co.nz>
Yet another 16550 clone under a different name. Why does device-tree
have a "compatible" setting if everyone puts a different name for the
same thing?
Change-Id: Ia889a527a36739df747ba48d4606c09764703607
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5103
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
They were hardcoded to 2, which is not correct on all devices. As a
result, getting addresses and sizes on pure 32bit devices would fail.
Change-Id: Icf542c9e8d6b7136219014fe08dd601387de4762
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5102
Reviewed-by: Fredrik Holmqvist <fredrik.holmqvist@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
If mprotect() is being run over an entire area, and the area does
not have per-page protections, then we can just invoke set_area_protection
instead of allocating a protections array.
This is a major efficiency increase, as every page fault would otherwise
have to use the protections array if it was allocated.
Testing with QtWebEngine shows this new path being hit relatively often
(multiple hundred times in loading a single webpage).
Change-Id: I60258d56f681060861602922f3fbdbce2fd380d6
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5097
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
* We should not assume all non-kernel areas have KERNEL_READ_AREA
permission, but follow the other permission flags directly.
This way the kernel will be blocked from accessing guard pages, too.
* Compute kernelProtection only once, and either return it directly
or return it OR'd with the user protections.
Change-Id: Id6daa1cd15eb3102e23f95c08672ad97344e0722
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5096
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
It already checks for area->page_protections == NULL and returns
area->protection appropriately if so, we do not need to test specifically
for that here.
No functional change intended.
It's entirely possible that we have a user area with a page that
has protections of 0 (e.g. a guard page). In that case we should
print the standard read/write fault message instead of "kernel"
fault messages.
This should not be a major behavioral change, only the syslog
and tracing entries should be affected; such memory accesses
should be caught by the read/write permissions checks immediately
following.
It seems this is the type of the innermost source cache, not the
topmost cache (which well may be "RAM" if this is an anonymous cache
on top of a Vnode cache.)
Originally VMArea::cache_type was introduced 15 years ago
(commit 0c12332715, 2007)
merely to mirror the underlying cache's type. Somewhere along the way,
it acquired different values. As the VM has changed a lot since then,
perhaps its overall purpose should be re-evaluated?
Fixes#17556.
If these methods are called while the interface in question
is receiving data via a receive thread, we can hit a deadlock
where a receive thread is holding the receive lock and then
tries to call get_interface_address_for_link (due, e.g., to ipv4
checking is_local_link_address), which tries to acquire the interfaces
lock, while at the same time we are trying to acquire the receive lock
due to CreateDomainDatalinkIfNeeded invoking a module's datalink_init
which calls register_device_handler, so we deadlock. (Whew!)
As far as I can tell, we do not need to set Busy() here despite unlocking
the interfaces lock, as the Interface acquires its own lock in
CreateDomainDatalinkIfNeeded.
Observed in VMware when the DHCP client spins for a long time,
and the deadlock occurs upon opening Network preferences.
Instead add a second level to the loop and a small temporary array.
Makes the code slightly simpler (and safer, as there is no risk
of races now.)
Also add a missing "firstCPU +" in the current_frequency calculation.
It seems that has been broken since the frequency value was introduced...
In addition to being slightly more efficient, this also allows one
to see precisely how many vnodes are currently "alive" across all
mounts via the "slabs" KDL command.
