* Fixes problems with setting the partition name after uninitializing
a partition in DriveSetup. Previously, UninitializeJob() was
followed by SetStringJob(), but the kernel was updating the
change counter for the parent partition when uninitializing a
partition, leading to SetStringJob() having an incorrect change
counter for the parent partition. Now the parent change counter
will be correct when SetStringJob() runs.
- According to the Be Book, one of BListItem::Update()'s responsibilities
is updating the item's internal height/width. However, while we were
providing such updates in the case of the item initially being added
to the view, or when the list view's font was changed, we were not doing
so on frame resize. This would lead to items having a stale width field
in such a circumstance, leading to possibly incorrect behavior in apps
relying on that field to be correct.
There are some delays in making the actual package repo generated by the
buildbot go live. Until then, I'm going to manually update the existing
repositories with the built packages, so people can start to experiment
with them and report any new issues.
There are more updates coming, but I'm doing them gradually so we can see
which set of packages triggers a regression, should one happen.
* Ingo rightly noticed that the defer_signals counter is reinitialized on
thread's user area creation. Setting the flag THREAD_CREATION_FLAG_DEFER_SIGNALS
indeed gives the expected behavior, deferring signals until undefer_signals() is
called in the child thread. Thanks for the review and fix suggestion.
* Added a simple test showing the values of the defer_signals counter after fork().
* This fixes booting Haiku when creating a brand new GPT
partition layout with the BIOS/MBR.
* This also fixes boot issues with UEFI based on OVMF, which
rejects GPT partitions that don't have the protective MBR.
* Also defer signals while registering fork hooks.
* While malloc provides fork heap hooks which lock the heaps and unlock/reinit,
malloc_debug provides empty hooks.
* Ideas suggested by Ingo, patch reviewed by him. Thanks a lot!
* Also call fork parent hooks on failure.
* Solve locks-up when combining multithreading and process forking, should help
with #13111.
It doesn't work, however; it throws an error message about failing to connect
to a port, which I presume was caused by the launch_daemon changes. If
Axel could take a look at it, that'd be much appreciated...
* There's no need to supply ways to mismatch the buffer duration
and size. Anything should reflect the media_format, this is at least
fixed on API level.
* There's no point actually in providing BTimeSource dependant
functionality. If and when there will be need for something like
that, possibly never, an higher level solution will be integrated.
If WP is not enabled then the kernel can freely write to read-only user
pages, which breaks copy-on-write.
Signed-off-by: Jessica Hamilton <jessica.l.hamilton@gmail.com>
This is separate to the VESA driver, as the VESA driver requires
using the VBE BIOS. Under UEFI, we don't have the VBE BIOS, nor
are we able to switch modes after leaving UEFI Boot Services, so
a dumb framebuffer driver seemed like the easier way to approach
the problem.
The framebuffer & vesa drivers now test for the presence of the
VESA_MODES_BOOT_INFO boot item to distinguish between which driver
to use. Also added check for the VESA mode count to determine
whether to add the VESA_MODES_BOOT_INFO item.
UEFI video updated to explicitly zero out the VESA and EDID
boot data.
The SpinLocker was always initialized to fThread->time_lock even though
fThread may be NULL. This looks like a simple oversight as the rest of
the method handles fThread being NULL and the team variants of these
timers have very similar logic and do the NULL check as well.
This fixes the last remaining KDL in the posixtestsuite.
DebugReportGenerator:
- In the case where the function was already disassembled beforehand,
we weren't retrieving the statement, leading to a null pointer
dereference.
According to the FreeBSD kernel malloc man page the allocator is
expected to return power of two aligned addresses for allocations up to
one page size. While it also states that this shouldn't be relied upon,
at least our (directly copied) bus_dmamem_alloc expects it and drivers
may depend on it as well. Looking through the FreeBSD commit logs, this
expectation seems to be rooted quite deeply.
This fixes watchdog timeouts in the ipro1000 driver under KVM and may
help with #11953. It might also be related to #9099 and #9601 as those
seem memory allocation related as well.
Revert "repo rework: Remove stubs; Breaks repo compat."
Revert "repo rework: Remove need for repos to be self-aware"
This reverts commit a2b2f4d642.
This reverts commit 602076ef82.
This reverts commit 5ffaf72c8a.
These changes break the build on Haiku and the ability to create repo
mirrors, for the lack of a replacement for the URL (an UUID was evoked
on the mailing lists, but not implemented).
We are due for a release soon, please don't break the build.
Revert "BNode: CID 602323 explicitly ignore fCStatus return value in ctor"
Revert "BNode: Set fCStatus in SetTo() explicitly"
Revert "BNode: Style fixes, see below for details"
This reverts commit ede463195d.
This reverts commit 6e3445098a.
This reverts commit 89c0b71c9a.
We are due for a release soon. Please keep things working.
Team:
- Adjust report generation event to include a final status code for listeners.
CliContext,TeamWindow,ReportUserinterface:
- Use aforementioned status code to indicate whether report generation
succeeded or failed.
DebugReportGenerator:
- Notify listeners if report generation fails. This may have previously
been responsible for some bug reports where it was indicated that the
debugger hung without exiting after being asked to save a report from
a crashed app.
- When dumping disassembly, retrieve it directly if necessary rather than
requesting it via the user interface listener. This also fixes the quirk
that requesting to save a crash report while looking at the source code
of a function would trigger switching it to disassembly visually.
- When walking the list of threads to dump, acquire references to all of
them before starting. Otherwise, it was potentially possible for a running
but not crashed thread to exit while we were generating the report, leaving
us with a pointer to a deleted thread. This was most likely the cause of one
of the crashes reported in #13082.
- When receiving the notification that source code state has changed, clear
the waiting function. Otherwise, it was potentially possible for us to get
other state change notifications, leading to the data semaphore being
released too often. This would then cause later potential waits such as
the stack frame memory dump to not actually wait when they should,
potentially leading them to dereference objects that weren't yet ready.
This fixes another of the crashes in #13802.
