does in fact happen, as there are objects used in the kernel that allocate
with new, which in turn uses the heap. The OpenHashTable used from the slab
allocator hit this case during an svn checkout here, because it grows it's new
allocated list by doubling the list size. Added some unconditional debug
output for those cases to monitor the usage for now. All of that not yet really
tested though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26216 a95241bf-73f2-0310-859d-f6bbb57e9c96
that looks like a compiler bug to me, though.
* Pulled struct data_stream out of the union (now called ext2_data_stream),
based on a patch by Maurice, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26214 a95241bf-73f2-0310-859d-f6bbb57e9c96
ext2_super_block::first_data_block must be used; the superblock offset
doesn't matter if the block size is greater than 2KB.
* Fixed block access beyond the 4GB limit - we need to cast the block to
a 64 bit type in ext2_get_file_map() before shifting it.
* Tested with various larger ext3 disks, and everything seems to work fine.
* Added some optional debug output.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26213 a95241bf-73f2-0310-859d-f6bbb57e9c96
(it didn't really work previously anyway). The only alignment really used seems
to be B_PAGE_SIZE, which happened to always work out before, because anything
larger would have been allocated using individual pages anyway. Since larger
bins are now available and with kernel heap leak checking enabled an allocation
of B_PAGE_SIZE with B_PAGE_SIZE alignment is actually a bit bigger than
B_PAGE_SIZE, it got into the 5KB bin, which didn't guarantee the alignment
anymore. This would have caused a tripple fault on boot when kernel heap leak
checking was enabled. The alignment is now taken into account when picking
the bin for the allocation. Added a more detailed TODO as to why this isn't
the best thing (wastes space) and how it could be changed if deemed necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26212 a95241bf-73f2-0310-859d-f6bbb57e9c96
Implemented the needed fs API hooks to support identifying partitions
(so ReiserFS partitions appear in the Tracker Mount menu now).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26211 a95241bf-73f2-0310-859d-f6bbb57e9c96
serve, bin sizes and page size. This minimizes the amount of "large"
allocations made in heaps that don't have a bin for the allocation size
(combining multiple pages). This is desirable as such large allocations
are generally pretty inefficient, and also because it separates larger from
smaller allocations better, making the chance of a heap becoming empty higher.
For now there are three heap classes "small", "large" and "huge", with a
predefined set of bin sizes for each. This might need some finetuning later on.
Reduce the grow size to 4MB though as the allocations should now be spread
across heap classes which each grow on their own.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26210 a95241bf-73f2-0310-859d-f6bbb57e9c96
allows for dynamic (heap)page sizes. It's currently just set to B_PAGE_SIZE
but I'm expermienting with the creation of differently sized heaps that could
use dynamic page sizes with that.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26203 a95241bf-73f2-0310-859d-f6bbb57e9c96
Report the index where the event opcode pair has been found.
Currently server was expecting them to be the first entry of the request
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26198 a95241bf-73f2-0310-859d-f6bbb57e9c96
the cancel, it wasn't actually done. This could bring a device out of sync in
the case timeouts actually happened (which shouldn't be a commen case).
Fixed that and increased the timeout to 2 seconds in favor of slower devices.
Might need some fine tuning later still.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26197 a95241bf-73f2-0310-859d-f6bbb57e9c96
Avoid unhandled event in the bluetooth_server
by Mika Lindqvist
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26196 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fixed race conditions when a ServerApp or ServerWindow is created. The
reply to the client that the object has been created successfully was
sent in the thread creating it. Preempted at the wrong time (right after
writing the message to the port) could lead to the object's thread using
the link at the same time, which would screw up all subsequent
communication via that link.
This fixes the problem that mimeset would sometimes fail when building
Haiku in Haiku (can't find the ticket). It probably also fixes#2331,
and the bug that sometimes when a window is opened (Terminal, crash
alert, shutdown window, etc.) it would come up with huge width/height
and tiny other dimension (can't find the ticket).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26192 a95241bf-73f2-0310-859d-f6bbb57e9c96
* It's not yet complete, doesn't support some ext2 stuff (like files over 4 GB),
and might have some other bugs (I only tested it with a single 20 MB ext2
image).
* To have a read/write ext2 file system, it would probably make more sense to
port GNU sources (like ext2fs lib), and use that. But a small read-only ext2
file sytem doesn't hurt, I think, and I don't know if ext2fs lib would be
feasible for kernel use (porting the file system from Linux directly would
also be an alternative, but probably more work).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26187 a95241bf-73f2-0310-859d-f6bbb57e9c96
the newly found disk systems.
* _ScanPartition() now allows to restrict the disk systems to a predefined set.
* _ScanPartition() now even scans partitions that already have a disk system
assigned; if a better one is found, the existing one is replaced. It will
ignore mounted or partitions with children, though.
* KPartition now also stores the priority of the disk system assigned to it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26177 a95241bf-73f2-0310-859d-f6bbb57e9c96
correct, but it prevents a deadlock that could sometimes be seen right after
booting when the Terminal was supposed to draw the decorator buttons. It
doesn't seem to cause any problems with locking removed (the original drawing
code didn't lock either). Added a TODO to investigate and eventually fix that
though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26170 a95241bf-73f2-0310-859d-f6bbb57e9c96
VLC, which for some reason calls CountItemsUnder(NULL) quite a few times on startup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26167 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Use the platform object to determine the platform type in system_info.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26166 a95241bf-73f2-0310-859d-f6bbb57e9c96
per cache.
* Changed the strategy vm_cache_acquire_page_cache_ref() uses to ensure
that the cache isn't deleted while trying to get a reference. Instead
of the global cache pages hash table lock, it holds the global cache
list lock now. We acquire + release this lock in delete_cache() after
removing all pages and just before deleting the object.
* Some small optimizations using the property that the cache's pages are
ordered, now (vm_cache_resize(), vm_page_write_modified_page_range(),
vm_page_schedule_write_page_range()).
* Replaced some code counting a cache's pages by simply using
vm_cache::page_count.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26160 a95241bf-73f2-0310-859d-f6bbb57e9c96
