To help understand the problem in #14276
Change-Id: I334a5cdfa149d335068f2135d13ed729b53fe6ab
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1900
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
As for other devices, N=1 makes no sense because N-2 is eventually
written to the hardware register, so wherever these values come from,
they can't be correct. Replace with the values from the Intel manual.
Also fix confusion as to when the + 2 or - 2 is applied to M1 and M2
values. The documentation says M1+2 and M2+2 are used in frequency
computations, but we instead write M1-2 and M2-2 to the registers, so
the M1 and M2 in our limit structs has an offset of 2 from the docs.
Should fix#13694.
Change-Id: I87157154d22a5e6caf622d71a2f0e0b9ff21a2fa
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1902
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This reinstates commit 2b5ebfcfd5.
According to the POSIX specification, a NULL iov_base means
"do nothing." So we should treat that as such properly,
and not consider it an invalid address.
Fixes#15356.
Change-Id: Ia9438777f1da8ca32f93e0d85229230c809e6711
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1918
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
The HAIKU_FIRMWARE_NAME_MAP macro takes a size parameter to define the
firmware map array type, and then a multi-dimensional array literal is
assigned to the array defined by that macro.
This is error-prone. The idualwifi7260 driver, before this patch, had
the size incorrectly set to 6 when the number of entries was 7, which
sliced the last entry off of the map, making it unavailable to the
driver. After fixing this size, the driver properly loads the
iwm-8265-22.ucode firmware on my computer.
This patch changes that macro to take a const char[][2] literal as its
only parameter, making it less likely for this sort of bug to be
re-introduced.
Fixes#15413.
Change-Id: I78a75e692a8637af0f13d1eb16180ce8d95d0852
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1917
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
This allows ARM64 to bootstrap for building of GCC.
Signed-off-by: Jaroslaw Pelczar <jarek@jpelczar.com>
Change-Id: Ia2ea34d1fc1a8e4d3c77a7ef05a32a8603a4fb51
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1851
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Change-Id: I3ccb6be54ba3e42136fa7093f35e16aaecc5a540
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1589
Reviewed-by: Chế Vũ Gia Hy <cvghy116@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
We have quite a few GSoC projects around this, it would make sense to
have some documentation for people attempting them.
Add some generic overview of filesystems and how to test them.
Follow up to #15135, which created a regression, apps would crash if
using the port pool before creating a BMediaRoster instance. Now the
port pool is entirely managed by the MediaRosterUndertaker, which is
less confusing.
Fixes the media_addon_server crash on shutdown for me as well, but I
don't remember why (I had studied the code and came to the conclusion
that this should fix it, but I don't remember the reasoning).
Fixes#15263, and regressions for apps using the port pool before they
instanciate the BMediaRoster.
Change-Id: I887dbc590d8ee9de391b6eae0206944bfe99325f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1897
Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
Change-Id: I88afad6d071e8b577c23da9c60392c60b3726514
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1895
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
* With them Debugger doesn't allow setting breakpoints inside functions.
* Workaround for #15159. Further explanation by anevilyak is also there.
Change-Id: I661b7dcb28a4c02f671b85cb5c26fa0bd5a53078
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1892
Reviewed-by: Rene Gollent <rene@gollent.com>
When unarchiving, we can rely on BView to properly restore the colors,
and we should not alter them. So move the code doing that outside of
_InitObject, and into all non-unarchiving constructors instead.
Change-Id: I98050c69bb3b8edf6e77ad0498e2dade5eaadb1d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1887
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
If you dropped a square image onto the image well, it was
squashed horizontally.
Change-Id: Ie5637fc242a1c5b7313234a87822bc43556cbe4d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1886
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
A HaikuDepotServer may have previously agreed to
user usage conditions. If this is the case then
they are now able to view those conditions. There
were some problems with date formatting in this
change and so the date formatting logic has moved
into the HaikuDepot source code temporarily until
issues with the BDateTime class can be resolved;
most likely as a separate piece of work.
Relates to 15209
Change-Id: Ic3e5413d9139f410d7f7e8b566d4c56352dd2778
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1870
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
fQuantumStart and fLastInterruptTime were not set to 0 here, so they
would default to the "malloc-cleared" data and then always overflow
the first time the interrupt time was tracked. I can't find any
reason that was supposed to be the behavior, so just set them to 0.
Also reorder the field initializations to be the same as the class
definition, which should allow some store merging optimizations.
Spotted by KUBSAN.
