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 reverts commit 21e3ac6cf52f91dba8217f15fc33dc1d45dffd40,
which was accidentally applied twice, missed during rebase.
Originally applied in 601b2f7eda4d25b46e7d17e212d22954f28bd0fe.
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 a2b2f4d6427914cdcdb59943dd8e4a0bfdcd53ee.
This reverts commit 602076ef82647a48fd10f4d1ec830bb4242f9eb6.
This reverts commit 5ffaf72c8a74a7eb6827e4d2b1f47c9360ddaefe.
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 ede463195dee8536628c54ee6a4a888c0683a83f.
This reverts commit 6e3445098abd1d1e4cca69ba2d959fe74fe2cb1b.
This reverts commit 89c0b71c9a5acdbdb4543f025f64937bfbd893e3.
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.
instead of setting it in _SetTo() and then again in SetTo()
fCStatus could be set even fewer times but this is a good compromise
(logically, performance wise it is not an issue).
Update copyright, add myself to Authors
Remove superfluous parens
Rename result variable to bytesWritten
Sync() Unwrap ternary style fix (for consistency)
* Shouldn't this return fCStatus instead of B_FILE ERROR?
* BeBook says "returning B_OK on success and an appropriate error message otherwise."
* Has returned B_FILE_ERROR since "it is accomplished ..."
Rename result variable to bytesWritten (again)
Remove superfluous space
explictly cast status_t to ssize_t
Remove superfluous parens, remove space, add newline
Explicitly cast status_t to ssize_t (again)
WriteAttrString() cleanup
* rename error to result
* rename sizeWritten to bytesWritten (consistency and clarity)
* check if error cede from WriteAttr and cast to status_t
* > not entirely style but functionaly same
* if length is different then written return B_FILE_ERROR
* > not a style change but a very minor functional change
* add some comments
Tiny documentation fix precede vars with \a
More style fixes
* Rename error to result
* Put parens around conditional of ternary instead of whole thing
* Compare against NULL explicitly
* Don't set fCStatus here, we're going to set it in the calling function instead
* > note that Unset() sets fCStatus to B_NO_INIT but that's ok
80 char limit style fix
More style fixes and don't set fCStatus
* remove superfluous parens
* compare ref to NULL explicitly
* > Also don't set fCStatus here since we will do that in calling function
Unset() sets fCStatus to B_NO_INIT but that's ok
Unwrap ternary style fix (consistency)
Rename error to result (again)
* Planning on having a notification box when updates
available.
* Clicking the notification box will pop up the
SoftwareUpdater with a simple "Apply Updates" button
* Currently users need to know to 'pkgman update'
* The media_kit isn't an hard real time beast. Bounding lateness
looked like the perfect way to enable reasonable soft real time
performance and thus limiting port writes and reads between producers
and consumers. It seems to don't work very well so I just remove it.
* The result of the recent code simplification makes it equal to my
first version, before any discussion on it happened.
* Thanks to AlienSoldier for testing such issues.
* Fixes #13069.
