sometimes not.
* This fixes CIDs 1755-1756, and 1505-1506.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38460 a95241bf-73f2-0310-859d-f6bbb57e9c96
headers and respectively added includes in source files.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37259 a95241bf-73f2-0310-859d-f6bbb57e9c96
anymore as that truncates physical addresses when PAE is enabled.
Now, if a 4 GB physical address limit is forced in DMAResource, the system
continues to work fine when the physical memory > 4 GB is used. Otherwise it
hangs or crashes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37134 a95241bf-73f2-0310-859d-f6bbb57e9c96
restrictions for virtual/physical addresses.
* vm_page_allocate_page_run():
- Fixed conversion of base/limit to array indexes. sPhysicalPageOffset was not
taken into account.
- Takes a physical_address_restrictions instead of base/limit and also
supports alignment and boundary restrictions, now.
* map_backing_store(), VM[User,Kernel]AddressSpace::InsertArea()/
ReserveAddressRange() take a virtual_address_restrictions parameter, now. They
also support an alignment independent from the range size.
* create_area_etc(), vm_create_anonymous_area(): Take
{virtual,physical}_address_restrictions parameters, now.
* Removed no longer needed B_PHYSICAL_BASE_ADDRESS.
* DMAResources:
- Fixed potential overflows of uint32 when initializing from device node
attributes.
- Fixed bounce buffer creation TODOs: By using create_area_etc() with the
new restrictions parameters we can directly support physical high address,
boundary, and alignment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37131 a95241bf-73f2-0310-859d-f6bbb57e9c96
warnings, but also some oversights from earlier changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37000 a95241bf-73f2-0310-859d-f6bbb57e9c96
that are wide enough for both virtual and physical addresses.
* DMABuffer, IORequest, IOScheduler,... and code using them: Use
generic_io_vec and generic_{addr,size}_t where necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36997 a95241bf-73f2-0310-859d-f6bbb57e9c96
of having the logic be triggered by IOScheduler::SetDeviceCapacity(), as that
one might actually be called more often (for each call to update_capacity(),
ie. each B_GET_GEOMETRY/B_GET_DEVICE_SIZE will trigger it), and there is no
reason to throw away the cache every time (will make a difference during
partition/file system detection).
* In cd_init_device() just call update_capacity() instead of duplicating its
code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36986 a95241bf-73f2-0310-859d-f6bbb57e9c96
map_physical_memory()'s physicalAddress parameter type from void* to
phys_addr_t. This breaks source compatibility, but -- as long as
phys_{addr,size}_t remain 32 bit wide -- keeps binary compatibility with
BeOS.
* Adjusted all code using the affected interfaces (Oh what fun!). Added a few
TODOs in places where the wrong types (e.g. void* for physical addresses
are used). Looks like quite a few drivers aren't 64 bit safe and others
will break with PAE.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36960 a95241bf-73f2-0310-859d-f6bbb57e9c96
implemented for any architecture yet.
* vm_set_area_memory_type(): Call VMTranslationMap::ProtectArea() to change the
memory type for the already mapped pages.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36574 a95241bf-73f2-0310-859d-f6bbb57e9c96
caching (similar to the file cache) instead of contiguous areas. This is
probably a little bit slower, but integrates better with the VM -- the
caching doesn't increase memory pressure and the least recently used pages
will automatically be recycled when needed.
There are still memory allocation issues on machines with little memory. The
USB stack apparently tries to allocate a rather big chunk of contiguous
memory, which fails when all not otherwise bound memory is used for caches,
since the VM functions for allocating contiguous memory consider only free
pages ATM.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36458 a95241bf-73f2-0310-859d-f6bbb57e9c96
as a drop-in replacement for IOScheduler, processing IORequests synchronously
in FIFO order. It stores cache lines of user-defined size. Currently for each
cache line an area of contiguous memory is used, which is not optimal.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36436 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Moved IOScheduler::_IOCallbackWrapper() to IOCallback::WrapperFunction().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36394 a95241bf-73f2-0310-859d-f6bbb57e9c96
driver_events (ie. there is now only a single list to walk).
* Also, the DriverWatcher is now maintained using the driver_events.
This fixes bug #5005.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35463 a95241bf-73f2-0310-859d-f6bbb57e9c96
argument. They replace the previous special-purpose allocation functions
(malloc_nogrow(), vip_io_request_malloc()).
* Moved the I/O VIP heap to heap.cpp accordingly.
* Added quite a bit of passing around of allocation flags in the VM,
particularly in the VM*AddressSpace classes.
* Fixed IOBuffer::GetNextVirtualVec(): It was ignoring the VIP flag and always
allocated on the normal heap.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35316 a95241bf-73f2-0310-859d-f6bbb57e9c96
device path + child partition name. When a "raw" device is unpublished the node
removal notification triggers the partition and child partitions to be
unpublished/removed. Since in that case the "raw" node is already unpublished
trying to resolve it in devfs_unpublish_partition() again to unpublish the child
partitions would fail, leaving the child partition nodes behind. When a new raw
device would then become available publishing its partitions would fail because
of these left behind nodes, causing bug #4587. Seeing that this code is more
compact and straight forward anyway I don't quite see why it was changed in the
first place.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34967 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Replaced the "userOnly" parameter by a "flags" parameter, that allows to
specify kernel and userland stack traces individually.
- x86, m68k: Don't always skip the first frame as that prevents the caller
from being able to record its own address.
* capture_tracing_stack_trace(): Replaced the "userOnly" parameter by
"kernelOnly", since one is probably always interested in the kernel stack
trace, but might not want the userland stack trace.
* Added stack trace support for VM cache kernel tracing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34742 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Lock the notification service and check HasListeners(), so we don't prepare
an event message needlessly.
* The on-stack buffer for the event message was too small for I/O operation
related events. Now a larger buffer belonging to the roster object is used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34737 a95241bf-73f2-0310-859d-f6bbb57e9c96
weren't terminated orderly.
* IOScheduler now stores its name and gets a unique ID.
* Added IOSchedulerRoster singleton which registers all IOSchedulers. It also
provides a notification service. We generate interesting events for
IOSchedulers, IORequests, and IOOperations.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34702 a95241bf-73f2-0310-859d-f6bbb57e9c96
IORequest::Wait(). Wait() immediately returned when IsFinished() returned
true, but this is the case as soon as the last IOOperation has finished. The
I/O scheduler is not done with the request at this point, though, since it
will still be sitting in at least one of three doubly linked lists. Since the
usual procedure to issue synchronous I/O requests is to create an IORequest
on the stack, pass it to the I/O scheduler, and Wait() on it, Wait()
returning early might cause the IORequest object to be destroyed while it is
still in use, leading to invalid memory access in the I/O scheduler,
corruption of its list structures, as well as later corruption of the issuing
thread's stack.
Related tickets:
* #4431: The request issuing thread returned and already deleted the area the
request was writing to before NotifyFinished() was called.
* #3048, #4883: Caused by the on stack IORequest being overwritten with other
data while being handled by the I/O scheduler thread.
* #4517: Hard to say, but I've seen a such a problem too, after a thread
scheduling related change. An explanation would be a list structure
corruption in the I/O scheduler causing an infinite loop with disabled
interrupts.
* #2845, #3428, #3429: The block notifier/writer is I/O heavy and as such
quite likely to run into the stack corruption issue.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34655 a95241bf-73f2-0310-859d-f6bbb57e9c96
* "Classified" VMAddressSpace, i.e. turned the vm_address_space_*() functions
into methods, made all attributes (but "areas") private, and added
accessors.
* Also turned the vm.cpp functions vm_area_lookup() and
remove_area_from_address_space() into VMAddressSpace methods. The rest of
the area management functionality will follow soon.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34447 a95241bf-73f2-0310-859d-f6bbb57e9c96
to physical memory whose address would accidentally satisfy the
IS_USER_ADDRESS() check.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34136 a95241bf-73f2-0310-859d-f6bbb57e9c96
parameter and request->IsWrite(). The parameter means whether we want to
write to the request's I/O buffer (therefore renamed it to writeToRequest),
while request->IsWrite() indicates whether the request is a write request.
One can only write to a read request's buffer and vice versa.
IOBuffer::LockMemory() also wants to know whether the request is a write
request, not whether we want to write to the memory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34135 a95241bf-73f2-0310-859d-f6bbb57e9c96
Mikhail Panasyuk: since worker threads often end up with B_NORMAL_PRIORITY,
it might be a good idea to give system threads a higher priority.
* Minor cleanup (mostly automatic whitespace).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33961 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Allow an allocator to be created on the heap to allow for non-locked
allocators to be created.
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33721 a95241bf-73f2-0310-859d-f6bbb57e9c96
is virtual already it just returns the vecs directly, if it is physical it takes
over the task of virtualizing the vecs either using vm_map_physical_memory_vecs,
if there are multiple vecs or more than one page, or falls back to page wise
mapping if mapping fails or is not needed. In the best case, scattered physical
pages are mapped into one linear virtual buffer so that subsystems operating on
virtual memory only get a single vector and can then burst read/write.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33524 a95241bf-73f2-0310-859d-f6bbb57e9c96
when scanning for drivers, as that reverts the standard locking order with
locks like the device manager lock. There is now a dedicated scan_lock for
each directory.
* get_device_name() now locks itself which also adds a missing lock in the
B_GET_PATH_FOR_DEVICE ioctl().
* Minor refactoring; the directory init code was duplicated over several places
in the source file.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33465 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Fixed vfs_get_vnode_from_fd() return type.
- Added vfs_open_vnode().
- Added a "bool traverseLeafLink" parameter to vfs_get_fs_node_from_path().
It was always resolving symlinks.
* device manager/devfs:
- devfs: get_node_for_path() no longer resolves leaf symlinks. That still
doesn't help with file disk devices, as creating partition wouldn't work
anyway.
- Pulled the module-related implementation part of BaseDevice into new class
AbstractModuleDevice and made all methods of BaseDevice virtual. Small
adjustments to devfs to be happy with the new BaseDevice interface.
- Added BaseDevice subclass FileDevice, which maps the interface to a file's
file descriptor. Still got a few TODOs, but should basically work.
- Use FileDevice for publishing file disk devices in devfs. Now those do
actually work, though there's some BFS trouble with one of the images I
tested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33385 a95241bf-73f2-0310-859d-f6bbb57e9c96
