Repository processing triggers HAIKU_REVISION computation, and it
is intended that the UserBuildConfig can override or set HAIKU_REVISION.
Fixes#14834.
This makes the output much easier to read (e.g. "write(...)" vs.
"_kern_write(...)") and similar to strace/dtrace/etc. output
on other platforms.
Change-Id: Iac8e32aae0dcf3731a348c6192203f8d5b54da7a
Reviewed-on: https://review.haiku-os.org/c/1451
Reviewed-by: Bruno Albuquerque <[email protected]>
It is very, very rarely used, and is extremely wide on some locales
(i.e. almost 2x the width of the other buttons combined), making it
appear out of place. Now that it can be done from Debugger, having
it here does not seem to make a lot of sense.
As requested and discussed in #14777.
* mutex_destroy() only checked wether or not there were waiters,
not if the lock itself was presently held by another thread.
Now we do, which should make #15015 panic much earlier instead
of trying to use freed memory.
* mutex_transfer_lock() and recursive_lock_transfer_lock() did
not check that the calling thread actually owned the lock.
Now it does, which should trigger asserts if anyone tries
to do this.
We need to call pci_ram_address() on the whole address, not just the
lower 32 bits, and then store both components inside the PCI info
(previously we were leaving the high bits unset.)
Very few drivers bother to check if the address is 64-bit or not,
and for the most part they don't need to care, since the PCI bus
is at 0x0 physically and will pretty much never get anywhere near
4GB in size. But the XHCI driver read these, and so would get
bogus values for the high 32 bits, as we were never setting those.
Probably fixes#15040.
cache_io() did some bounds checking, but for uncached reads it was
entirely on the filesystem. Now we are more consistent: do all the
bounds checking for reads in the file cache, and do all bounds
checking for writes in the filesystems.
This makes sense as nearly all file systems were doing the exact
same logic for read() but of course all have different logic
for write(), due to block allocation, etc.
This potentially fixes#14993.
Change-Id: Iaf3e549001344cf375c7b8de549fc169d77bdbb2
Reviewed-on: https://review.haiku-os.org/c/1420
Reviewed-by: waddlesplash <[email protected]>
The package kit calls this function to print errors it hits
when reading packages. We should never hit this in "normal
operation", but it should help with debugging #14993.
Inside the device_consumer thread, the sequence of operations was this:
1. Call fifo_dequeue_buffer()
2. If it returned B_INTERRUPTED, exit the thread. Otherwise, process
the buffer it returned as normal.
3. Loop.
Thus, if the FIFO was destroyed not during a call to
fifo_dequeue_buffer, the next loop, fifo_dequeue_buffer would
be called on a destroyed FIFO. It would then try to lock the mutex
in the FIFO which had been destroyed, causing an assertion failure
and thus a panic.
Now, we check the ref_count on every loop, and set it to 0 before
calling uninit_fifo(). Thus, even if we are in the middle of a loop
inside the FIFO thread, the loop iteration condition will fail
and thus the thread will exit, avoiding the race.
Probably this was not an issue before because the timing required
to hit this is incredibly unlikely. With the new ipro1000 driver
(or kallisti5's WIP TUN/TAP driver), the timing makes this much
more likely.
Should fix#15024.
On VirtualBox, the reported maximum transfer size is 2MB; but all
I/O >= 753KB fails in an identical way to the "maximum size" failures.
In other news, there are multiple open tickets in the VirtualBox
tracker about Linux systems failing to boot off NVMe...
I tested with a hacked-in maximum segment size of 752KB and everything
seemed to work just fine. Writing a HPKG to a FAT partition on NVMe,
rebooting, and then reading back the HPKG showed it had the same
sha256sum as the one stored in /system did. So this is working!
Before this commit, only one qpair was allocated and it was
locked for the duration of the transfer. Now we allocate more
qpairs if the device supports it and lock only when actually
calling read(), enabling multiple reads to both be queued
and execute simultaneously.
This is probably a significant performance improvement,
even more so than it is/would be for SCSI, as SSDs
can actually read from as many sectors as bandwidth
allows at once.
As the comment implies, we don't want to wait here, but low_resource()
waits forever when timeout=0. It doesn't seem to do anything with the
"size" argument at all, so not calling it is just as effective, and so
replace the comment there altogether.
The case where this was most often hit, causing a full system deadlock
in anything relating to memory management, was when the passed "size"
was 0. So now we check for this case explicity at the beginning and
panic() on KDEBUG kernels for it.
This is the cause of #14557. It seems that OpenBSD does the same thing.
I didn't read the spec yet to determine precisely what this means,
so for now, just do what OpenBSD does and bail.
This only seems to happen with a secondary XHCI controller on that
device, so hopefully most USB ports will still work.
The previous version did not account for the position not being a
multiple of the block size, among other problems.
Tested by hand with DiskProbe and then "dd skip=..." to read single
bytes from partial blocks, and validated as correct.
Only one qpair is used for reading, which is rather inefficient.
We currently allocate a bounce buffer for every allocation, which is
also inefficient, due to the fact that we must read an integer multiple
of LBAs.
But it does work, and it is actually reasonably fast, even on an emulated
machine using a spinning-disk-backed NVMe device (88MB/s.)
I wasn't able to get it working in non-packaged, though; the device manager
called supports_device() on a number of PCI devices, but not the NVMe
device, so I have a different version with a hack that grabs the PCI info
manually. I didn't test inside haiku.hpkg yet; perhaps it will work in there.
Previously it was possible that we put() them twice, leading to
assert-failure panics as their ref-counts would go below 0.
Now we get() them once for every bus object that we create, as
the destructors put() them.
Should fix the panic in #15004.
It is called before them (and is responsible for calling them),
so having it in the middle of the file does not make a lot of sense.
Already done for XHCI. Only one functional change -- removing the
set_dprintf_enabled call. Drivers probably shouldn't spuriously
re-enable that if it was specifically disabled.
FreeBSD has the names we used before this commit; OpenBSD has names
more similar to the ones used in this commit (though following their
conventions of course.)
This makes the code significantly more readable.
This set is only used until the SetupEnvironment script has run, i.e.
for launch_daemon and its initial tasks, which does not need the user
paths. Solves a TODO.
We don't reschedule or block in here, so checking for interrupts
is needlessly strict. Sorry for the noise, forgot to remove this
before the previous commit.
This codepath is only hit when we are using the GCC2 demangler,
so we should not use get_next_argument which tries to autodetect
what kind of symbol this is.
We have not one but two internal caches in packagefs for *uncompressed* data;
we do not need the underlying filesystem to cache the *compressed* data
needlessly.
This seems to be a negligible memory and boot speed improvement at best,
although it will likely help in low-memory situations in reducing
the pressure on the file cache (... actually it doesn't look like
the file cache responds to low resource notifications at all, which
may be relevant here.)
The current version is "v2", and it has been since the final PM branch
was merged back in 2013, so it's unclear if anyone actually uses this
file format. The "package" command can still of course read these
files, it's just that packagefs will now not be able to.
It's very unlikely anyone is impacted by this change.
* There is now a 'busses' folder, and the extant USB/SDHCI/Bluetooth/etc.
docs now live in it, instead of various other places.
* kernel/ports is now kernel/arch, like it is in src/system.
SPARC documentation is now in there, too.
* VM files (these are rather outdated) are now in kernel/vm.
* SCSI ASC info removed, this is easily available online and
it doesn't seem to be very relevant.
By default, all targets support the "haiku" platform, and we no longer
support building for BeOS, Dan0, Zeta, or other BeOS-compatible targets,
so this is no longer needed.
Also remove all references to the non-Haiku compatible platforms, and
change all BEOS_COMPATIBLE checks to HAIKU_COMPATIBLE. Removal of
all SetSubDirSupportedPlatformsBeOSCompatible invocations
will be in the next commit.
This one had an uncertain "freeware" license, and the code quality
is not so great. BeOS didn't have an 'uptime' command, so we can
replace this with the coreutils one without worry.
* firewire and freebsd_network expect the macros come from
sys/param.h, as this is one of the places FreeBSD defines them
* All others are Haiku-native and can use Be-style macros.
Fixes the build breakage caused by PulkoMandy's recent commit.
Remove these from ByteOrder.h now also, as per POSIX they should
come from netinet/in.h.
This is a small source compatibility breakage, but it will only
affect a small portion of non-POSIX, partially-Be applications.
If this triggers, it means something is using the "build" errors while
the build system thinks it is not, which is always an error. Nothing
triggers this at present, but some subtle bugs in the build system
a while back would have been caught by this.
* Actually use the global mutex instead of creating useless MutexLockers.
* Don't delete the device object on _free(), then it can't be opened again,
which we want to be possible. Matches the behavior of other audio drivers.
* Clean up device detection code to better match other drivers.
At least under XHCI, multi_audio_test throws a variety of errors and then
crashes while attempting to use this driver. But following implementing
CancelQueuedTransfers, the system no longer KDLs after that. Progress!
Seems to work OK on my hardware now. Possibly helps with device unplug/replug
issues; though that worked on my hardware before this change, too. This is
now more correct at least.
* Check "endpoint == NULL" instead of the ID for this pipe; as
_InsertEndpointForPipe will have already done the check for us.
* Store the endpoint's ID (our internal ID) in the structure, and
then move the doorbell-ring into _LinkDescriptorForPipe. Now all
variables named "id" are actually that, and not the endpoint number
(which is "id + 1".)
* Return actual statuses in NotifyPipeChange, among other tweaks.
* All things which set the usb_request_data structure also set data,
so we can just use ReadDescriptor to do copies like normal, simplifying
the finish-transfers code.
No (major) functional change intended.
* Remove code duplication.
* Make _mutex_trylock work in non-KDEBUG kernels. This should fix
spurious failures to lock in drivers compiled for KDEBUG kernels
running under non-KDEBUG kernels.
This requires a bit of massaging around the locking code. Probably
we shouldn't be able to do this, and there should be a "mutex_unlock_etc"
for use in interrupt contexts, but at present there is not.
This makes it possible to use XHCI-attached keyboards from within KDL!
This is not so important now (though it is a mild performance improvement
when running transfers during commands), but it will be when the debug
transfer hooks are implemented, as we will need to use these to determine
if it is safe to queue and poll for transfers or not.
The code as it was before was very hard to follow and incorrect in
a number of corner cases, as well as not being very clear about what
the TODOs were.
It now follows the spec much more closely (especially in interval
computation) and contains more details on where it is still lacking.
This probably does not fix much (if anything) as is, but it paves the
way for future isochronous support.
See inline comments. At least in brief testing I couldn't cause the
USB-HID stalls anymore, but they were very intermittent for me anyway.
But it was doubtless the case that the logic as it was before was
very much incorrect.
Besides calling the allocator fewer times, this also helps break up
the size classes we are allocating chunks from, reducing memory pressure.
As most transfers are smaller than 128KB, this is a major performance
optimization for them.
Augustin Cavalier