I didn't do anything with sparc for a few weeks (you don't want this
machine running when temperatures already are over 30°...), and I wastd
some time finding back some of the useful information, such as commands
to boot and debug, load and execution address of the bootloader program,
etc. So let's keep these in the documentation directory.
Change-Id: I293e0eea3063d410d66f9b2397c2cf0bdbfc6753
Reviewed-on: https://review.haiku-os.org/c/1581
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The sparc openboot implementation can run executables in the a.out
format. We used to generate these using objcopy, but this does not work
anymore as binutils is deprecating a.out format support.
- Import elf2aout from FreeBSD
- Add some missing bits to our elf.h and have a copy of it in the build
headers so it can be used to build elf2aout for the host platform
(tested for Linux)
- Use it to generate the sparc haiku_loader
- Adjust the bootloader linker script to have two "program headers": one
that is not loadable and contains the ELF headers, and the second one
that is loadable and contains the actual code and data. Unlike
objcopy, elf2aout relies only on the program headers to know what to
put in its output file (sections are ignored), so this is required
otherwise we end up with the ELF header nested inside the a.out file,
and everything offset from the expected load address as a result.
Confirmed that this allows to build the loader and run it as far as
before, so I'm back to needing to implement some MMU support now.
FreeBSD commit: 7551d83c353e040b32c6ac205e577dbc5f2c8955
Change-Id: I90b48e578fa7f148aeddd8c5998fdddc5cfa73fa
Reviewed-on: https://review.haiku-os.org/c/1557
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
We now record how long it takes to write a block (on average), and then
utilize this information to reduce the timeout write thread's timeout
(to 2 * block_count * average_block_time, so we don't completely
congest the drive.) Remove the "TODO" about the I/O scheduler;
this new logic will be just fine even under an I/O scheduler.
Note that this change goes both ways: while faster writes mean more
writes and quicker, slower writes will increase the timeout before
we do another one also. This then also guards against queueing
another write while one is already in progress, which was
not handled before.
Tested in KVM. Even on a SATA-backed spinning HDD, this reduces
the timeout to around *200ms* on average (!!), so a 10x improvement.
On a ramdisk, it reduces the timeout to *10-30ms* (!!!) on average,
so a 100-200x improvement, so this change will benefit everyone
but SSDs especially.
Since BFS inode and journal writes always go through the block_cache,
this very dramatically improves inode-related write performance.
The "stop and start" stutters when emptying or moving items to Trash
seem totally gone, among a lot of other things.
Change-Id: I41f46a6432ce1f50f896a853abdfe22dde0ba327
Passing a type& to a va-args turns it into a pointer as per
the Itanium ABI; but we shouldn't rely on such trickery.
Explicitly capture a reference to it instead.
This was (following the packagefs changes) the number-one (by call
count) consumer of malloc() during the boot -- 52866 calls, and 100%
of them either 1024 or 1025 bytes!
Virtually all of these are ephemeral (indeed, the object_cache
stats after a boot with this patch shows there is only a single slab
of 64 buffers allocated, and most of them unused), so this is
probably a significant performance boost.
Change-Id: I659f5707510cbfeafa735d35eea7b92732ead666
In cases where scsi_periph checks the size of the buffer supplied to an
ioctl call (functionality added in commit ff4af513e1) this information
needs to be provided by the caller to avoid failure.
Fixes#15094.
Change-Id: I37f2776edbe977e9825ec1837fb763a3b2aa7220
Reviewed-on: https://review.haiku-os.org/c/1584
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Terminal calls this multiple times a second per open tab, so it
was spamming up my malloc logs. I don't see any reason this 60-byte
structure needs to be on the heap; so, leave it on the stack instead.
Change-Id: I3f1ac14fe9bfec39cd0d5668c68f84467450b0c0
Reviewed-on: https://review.haiku-os.org/c/1580
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
cache_listeners are (following packagefs changes) the second-most
allocated object during the boot process, with 20799 on a
*minimum* image. Since they are used so extensively in BFS I/O,
making them object_cached for both performance and memory reasons
seems to make a lot of sense.
Change-Id: I6ef6c3e811c0c4189fea45ee7920131796c9e7c8
Reviewed-on: https://review.haiku-os.org/c/1577
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
Only keep a single block when there is a "critical" low resource state.
Also don't bother doing anything if there are no unused blocks.
Change-Id: Ibfcbd8cb0beb1446083ca83030ea8e81c59a9628
Reviewed-on: https://review.haiku-os.org/c/1576
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
TwoKeyAVLTree in packagefs is used for indexing. On a stock nightly,
just after boot there are 3 TwoKeyAVLTrees with just over 28000 items
each. So, this is another significant load off the generic allocator.
Slab statistics from KDL show that on a stock nightly image
(i.e. no additional packages besides the standards installed)
there are 43848 *objects* (not bytes) in the PackageNodeAttribute
cache, and 25090 in the PackageFile cache, so this seems more than
worth it.
The last commit seems to reduce memory usage at boot by about 1%,
this commit seems to not affect it at all; but it is a significant
performance optimization and on systems with more packages installed
the effect may be very noticeable.
Change-Id: I676a642ed6003f82b14396e1f02684575d899362
Now that we never access V1 packages in here, we don't need this.
This saves *24* bytes off the size of the class, which is
extremely significant as not only every PackageFile instance
has an instance of this class, but every PackageNode does too;
so the savings from this change is probably in the MB.
If the buildbots were working, I would have been informed of this
about an hour after I committed it last night. But it seems they aren't.
Maybe kallisti5 will have some more incentive to work on that?
Cleans up some lock/get/unlock sequences, and makes it possible
for external consumers to get team structs (which will be necessary
for permissions checks.)
This reverts commit 63895cb5f2.
This does go against the specification, and on a very small set of
XHCI hardware, seems to break booting (#15137). So, let's revert it;
the buggy hardware it potentially helped will just have to deal with
it.
Change-Id: I7dbbb5be0dd56b2a0b5148a4f7f81c66b76e9632
Reviewed-on: https://review.haiku-os.org/c/1554
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Change-Id: I291ebc949d63860e20eb609e4d3d2f600309d4e9
Reviewed-on: https://review.haiku-os.org/c/1553
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
- In Service, check that the device is open.
- In Close, clear dangling pointers to more easily spot problems and
avoid risk of accessing freed memory.
Change-Id: I970c4b8b8ec14db448388f74fc275634801c359a
Reviewed-on: https://review.haiku-os.org/c/1551
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Let's make it easier to keep them in sync for now.
Change-Id: Ic0f1488c7f7da7770db56c25d07fb3ead5e3649e
Reviewed-on: https://review.haiku-os.org/c/1550
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
This should not be necessary due to a note in the specification,
but it seems some controllers may not obey that; see inline comment.
Possibly fixes the "mouse slowness" of #15115 that began following
the Event Data changes.
The spec generally requires this feature, but some emulated hardware
(e.g. QEMU) does not support it. SPDK seems to just ignore the
error and continue on with a warning, so let's do the same here.
Change-Id: If11a892665d08f61c46b5a6a5b4bf0453225c3ee
Reviewed-on: https://review.haiku-os.org/c/1533
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
