new filesystem interface.
* Renamed sISO* to gISO* though as they are in fact not static.
Briefly tested and works as expected. Thanks for your work Dustin!
Closes enhancement #2089.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24994 a95241bf-73f2-0310-859d-f6bbb57e9c96
was, thanks to the detailed instructions from Ingo, quite doable.
* Ported the (deprecated and now publically removed) notify_listener() calls
to the respective new notify_* calls.
* Fixed debug build.
* Added the FAT filesystem back to the image.
I only tested the filesystem briefly and everything seemed to work as expected
(mounted the FAT part of my bootable Haiku memory stick, opened a few files
and copied something to it). At least it should not be any more broken than
before the interface changes ;-).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24987 a95241bf-73f2-0310-859d-f6bbb57e9c96
1 second instead of half a second. Might help with slow BIOSes.
* Disable EHCI interrupts if the BIOS handover fails so that we do not flood
the system with interrupts if the BIOS later on decides to still comply with
our handover request.
* Add an unconditional success message to EHCI and UHCI to better see if
controllers are present/initialized correctly at all.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24980 a95241bf-73f2-0310-859d-f6bbb57e9c96
in. We do not enable this interrupt and if we still "handle" it in our
interrupt handler we might prevent the interrupt from reaching the real intended
handler in a shared interrupt setup. Not sure if this could have happend at
all, but this is more correct in any case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24965 a95241bf-73f2-0310-859d-f6bbb57e9c96
constructor the object can be safely deleted (as documented for bug #1473)
* Some simplifications by caching the Pipe object for a transfer
* Minor cleanup
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24954 a95241bf-73f2-0310-859d-f6bbb57e9c96
handing them over to the USB stack. Otherwise the finisher (kernel) thread
would have no way to fill those packets when they came from a user space
address range. Completely untested though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24947 a95241bf-73f2-0310-859d-f6bbb57e9c96
read_next_module_name(). This is ugly and less flexible but it allows us to
explicitly force an initialization order. As detailed by the added comment
there seem to be controllers/BIOSes that require the EHCI controller to be
initialized after the companion host controller or else they refuse to publish
any high speed devices. This was the case for bug #1236 and my laptop when
legacy emulation is enabled and any device was plugged in at boot. This change
fixed the problem for me and hopefully closes bug #1236 too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24926 a95241bf-73f2-0310-859d-f6bbb57e9c96
initialization as suggested by the EHCI spec and do not touch it again
once the controller is running. Doing so would result in undefined behaviour
according to EHCI specs.
* Set the port routing policy after the controller has started and not before
as suggested by the EHCI specs.
* Explicitly set the segment register after resetting the host controller and
not before, as this likely has no real effect ;-)
Might help with some legacy support or UHCI/OHCI to EHCI handover problems.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24925 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_{READ|WRITE}_AREA. Otherwise we'd allow any user process to shredder our
data as Axel put it so nicely ;-) Thanks for the clarification.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24921 a95241bf-73f2-0310-859d-f6bbb57e9c96
when they are not open or they are deleted on free when they are already
removed. This should fix the sudden crashes when you unplugged a device that
might not have been fully closed yet.
Also handle the case of removal correctly and don't use the usb_device anymore
after releasing it by returning from the device removed hook. Calls to the
device just return B_DEV_NOT_READY in that case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24920 a95241bf-73f2-0310-859d-f6bbb57e9c96
KDEBUG on by default which causes benaphores to always use their semaphore.
Therefore when initing the benaphore with the inline compatibility function
and then using it using the lock.h provided inline would always cause a
deadlock and a hanging system under BeOS. Also we now (re-)define the
B_KERNEL_{READ|WRITE}_AREA defines for non Haiku targets to 0 apparently which
would probably also cause the stack to misbehave. Therefore they are now
just redefined (again) to plain B_{READ|WRITE}_AREA in BeOSCompatibility.h.
Change the inclusion order in some places so things work as expected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24894 a95241bf-73f2-0310-859d-f6bbb57e9c96
with B_USB_* and the command union is now usb_raw_command.
* Changed usb_raw and the BUSB* classes accordingly.
* Moved the raw_device struct into usb_raw.cpp as suggested by Francois as it
was the only thing usb_raw_private.h defined.
* Removed usb_raw_private.h again because of the above.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24861 a95241bf-73f2-0310-859d-f6bbb57e9c96
name, as it in fact is like a kit in the kit. It combines the different BUSB*
classes as compared to SerialPort.h where there really is a 1:1 relationship
between the header and the (one) class. If someone has a better fitting name
please shout.
Separated the usb_raw.h into usb_raw.h which defines the protocol and
usb_raw_private.h which holds the internal device structure for usb_raw. This
reduces the header dependencies.
Hopefully cought all occurencies of USBKit.a usage (in usb_dev_info and
the usb_webcam media add-on) but might have missed something that is not in
the image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24858 a95241bf-73f2-0310-859d-f6bbb57e9c96
usb_interface_descriptor of an alternate interface without having to switch
to it.
* Add some reserve bytes to all classes and add some reserved virtual slots
where the objects are publically constructable.
* Remove the source compatibilty defines that were briding the old USB* with
the new BUSB* class names.
* Implement the usb_raw side of getting an alternate interface descriptor.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24842 a95241bf-73f2-0310-859d-f6bbb57e9c96
on a patch by Salvatore Benedetto, adapted to the usb_raw interface by me
* Added two convenience functions IsStalled() and ClearStall() to USBEndpoint
Both changes are actually untested, so if you have a use for them and encounter
problems please shout.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24837 a95241bf-73f2-0310-859d-f6bbb57e9c96
clearity as suggested by Philippe Houdoin once and brought to my attention by
Slavatore. As this definition is completely private to the USB stack it would
not have caused any conflicts though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24828 a95241bf-73f2-0310-859d-f6bbb57e9c96
also free the device info which it must not do, as this info is in fact just
a pointer to the device info of the raw node. Removing a raw device that had
partitions published therefore always lead into KDL when closing the raw
device after unpublising the partition, as the close_hook pointer which sits
in the device info now was 0xdeadbeef. This should make for example unplugging
USB devices work as expected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24827 a95241bf-73f2-0310-859d-f6bbb57e9c96
based one. The path based version could not have worked for entry removed
notifications at all as the node is removed from the directory at this point
already
* Forgot to delete the device watcher instance after removing all monitors
* The PartitionRegistrar in DeleteDevice() was set to already locked which is
not the case
* Someone probably forgot to add a PartitionRegistrar to the media checker - it
did register the device on each run but never actually unregistered it, which
obviously messed up the reference counting a bit
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24815 a95241bf-73f2-0310-859d-f6bbb57e9c96
and ino_t instead of a path. Supposed to work with node monitoring messages.
Took the name from vfs_entry_ref_to_path() that takes the same arguments, but
suggestions for a better name are welcome.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24813 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also updating device->open_count must be protected by the device list lock
This fixes the (unlikely) case where a device was removed from usb_disk
standpoint while it still had an open read/write/ioctl operation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24811 a95241bf-73f2-0310-859d-f6bbb57e9c96
configuration of a root hub
* Cut down on number of retries to set the initial device address
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24804 a95241bf-73f2-0310-859d-f6bbb57e9c96
that do not support it (probably because they do not have a cache at all like
in flash media) and this should at least avoid spamming the syslog when this is
the case. It will try 5 times and then disable syncing for that device. Untested
as of yet though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24803 a95241bf-73f2-0310-859d-f6bbb57e9c96
* A device now has one or more LUNs which are used for LUN specific functions
* Adapted these LUN specific functions to the new design and also change the
(un-)publishing accordingly
* Handle "no media" cases more correctly
* Output some interesting device infos also with tracing disabled
* Add some more helpful debug output here and there
Devices that provide multiple logical units (like those n in 1 card readers)
should now be usable with usb_disk too. Also we don't fail when a device is
attached which currently does not contain a media. Instead handle media changes
correctly so inserting a media works as expected. Note that hot-unplugging and
media removal still does not quite work right at the devfs or disk device
manager level and easily crashes the system.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24799 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added {Create|Delete}Device() analogous to {Create|Delete}FileDevice
* Added a small DeviceWatcher class that reacts to entry creation/removal
* Implemented a way to start/stop node monitoring
* Start watching for devices after the boot volume has been mounted and the
the second initial scan was run
The disk device manager now creates and scans a device when a "raw" node is
published and deletes the device on removal. This makes hot-plugging of disk
devices (for example memory sticks using usb_disk) work. Their partitions will
be scanned and published so they can be mounted. Somehow the removal of the
partitions does not yet work however, any insights are welcome.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24777 a95241bf-73f2-0310-859d-f6bbb57e9c96
allows event listeners to add new listeners inside a node monitoring event
(i.e. if one wants to add a listener for the entry that has just been created
and triggered the current notification).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24760 a95241bf-73f2-0310-859d-f6bbb57e9c96
Instead return the directory vnode, so the calling function can insert it after
all vnode initialization is done. Otherwise entry created notifications are
sent upon inserting the node into the directory for vnodes that are not yet
fully initialized (i.e. they have no type or the device hooks are not yet set).
That would cause for example ioctls to fail when someone would react to a
notification of a newly created device.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24759 a95241bf-73f2-0310-859d-f6bbb57e9c96
intel_extreme driver and agp_gart. These worked for me for quite some time now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24730 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use the CBW_SIGNATURE define instead of the numeric value
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24729 a95241bf-73f2-0310-859d-f6bbb57e9c96
before routing them from the BIOS. Also clear pending SMIs when disabling
legacy support. Might help with some legacy support issues and probably
introduces others instead...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24728 a95241bf-73f2-0310-859d-f6bbb57e9c96
stack. The root hubs do not really need a powerup delay and as they are not
used until all initialization is done, this gives plenty of time to stabilize
the power. Therefore remove the powerup delay for root hubs and reduce the
stabilization time to zero. Also remove the define for the first explore delay
as it is not used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24727 a95241bf-73f2-0310-859d-f6bbb57e9c96
the bulk-only class using transparent SCSI commands (i.e. most of the current
external harddrives and flash media). It emulates the few SCSI commands needed
to get this sort of devices working and does not interface with the SCSI
subsystem. This makes it far easier to get working and also far better fits
how the USB stack works (as drivers can be dynamically rescanned when device
changes occur). This will allow for easy dynamic un- and replugging at runtime.
Note that while the device is currently published when you plug something in at
runtime, the partitions are not scanned and published automatically. It works
however if you have the device plugged in at boot.
I haven't added this driver to the image yet, but if properly installed and
with boot module links to the driver and USB stack, it allows to boot Haiku
from USB media like memory sticks or external harddrives.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24713 a95241bf-73f2-0310-859d-f6bbb57e9c96
pages calls of the fat filesystem to return an error instead of the effective
result. Please shout if this was done on purpose. I tested a bit with a fat
volume and where it failed previously when opening files it now works as
expected.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24711 a95241bf-73f2-0310-859d-f6bbb57e9c96
use the index of the first page of the allocation as an id. This removes the
need for separate id generation. This also fixes the possible problem of
multiple large allocations getting the same allocation_id (due to the limited
range of possible ids), which in the worst case (i.e. for adjacent allocations)
could cause pages to be freed that were still in use.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24405 a95241bf-73f2-0310-859d-f6bbb57e9c96
the new sematic of transfer_area so a message area is transfered into the right
teams' address space and it does not need to be cloned there anymore. Passing
by area is only used for messages bigger than a certain size (currently
hardcoded to 40KB) which should be somehow bound to the max port message size.
This makes passing large messages (i.e. > the port limit) possible, so for
example copy&paste of long text, image data, etc. should now work.
Got rid of the fClonedArea member as it is not necessary with the new design,
renamed shared_area to message_area in the private message_header, avoid
an unnecessary allocation of the header for the copy constructors, check
allocations in a few more places and some minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24321 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the resolved ToDo, but could probably be made more efficient. Instead of
transfering the area, the area is cloned into the target teams' address space
and the original is deleted. This generates a new area_id for the transfered
area (as suggested by the ToDo). Updated syscall prototypes according to the
status_t to area_id return type change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24320 a95241bf-73f2-0310-859d-f6bbb57e9c96
Maybe this needs to be extended to plain R5 as well, but I cannot currently
test that.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24210 a95241bf-73f2-0310-859d-f6bbb57e9c96
correctly (or at all...)
* Use the common 0xfffd character as a substitute for invalid characters
* Corrected comment
This function is used by the app_server to convert the UTF8 strings to char
codes to feed FreeType. Using a non space substitute character at least for
now, as it makes it more obvious where invalid characters are present.
I tested this change with some UTF8 test files and it seems to work well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24175 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the image to be skipped. Magnify therefore showed a white frame as long as
the area around the cursor would not change. Fixes bug #598 (again). I wonder
why this didn't show up earlier though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24156 a95241bf-73f2-0310-859d-f6bbb57e9c96
vector are unhandled, it is disabled if it is not a shared interrupt vector
(as before). Otherwise a message is printed to indicate the condition. I
reduced the amount of interrupts to 10000, as with 100000 it would take over
half an hour on my machine to trigger. Feel free to adjust.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24146 a95241bf-73f2-0310-859d-f6bbb57e9c96
unhandled. Otherwise it brings more trouble than it solves as it also disables
the interrupt of other devices (most often USB or network).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24120 a95241bf-73f2-0310-859d-f6bbb57e9c96
entire screen when exiting the kernel debugger. It sets up a thread that sends
a message to the (currently hardcoded) desktop message looper. The desktop then
does mark the whole screen dirty which causes a full redraw.
Since interrupts need to be enabled I went with an asynchronous thread and
releasing a request sem in the add-ons' exit hook.
Added the add-on to the image as it shouldn't hurt to have it for now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24025 a95241bf-73f2-0310-859d-f6bbb57e9c96
size of a reallocated block. If you had kernel heap leak checking on, this
could have caused the first four bytes of the next block to be overwritten
with the size of the reallocation of the previous block.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24011 a95241bf-73f2-0310-859d-f6bbb57e9c96
This eliminates the edge case where the grow thread would not be able to create
a new area because no memory could be allocated for the allocation of the area.
As this case cannot happen anymore, it is also not possible to deadlock in
memalign. Therefore the timeout (which would only have prevented the deadlock
but wouldn't have solved the edge case anyway) has been removed too.
Add options to dump the dedicated grow heap and to only print the current heap
count to the "heap" debugger command.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23994 a95241bf-73f2-0310-859d-f6bbb57e9c96
total count of allocations and bytes.
* Also add a few more bin sizes (for 8, 24 and 48 bytes) turns out especially
allocations of 20-24 bytes are pretty common. And as it only wastes a few
bytes per page this doesn't hurt at all.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23961 a95241bf-73f2-0310-859d-f6bbb57e9c96
heap leak check info would otherwise be overwritten for allocations that still
fit the 16 byte bin (i.e. allocations of 0-4 bytes).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23956 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Tracing of allocations, reallocations and frees
* Leak checking infrastructure to dump allocations
The leak checking code records the team and thread id when an allocation is
made as well as stores the originally requested size. It also adds the
"allocations" debugger command that can dump all current allocations (usually
a huge list) or filter by either a team or thread id. This way it's easily
possible to find leftover allocations of no more active teams/threads.
Combined with the tracing support one might be able to track down the time and
reason of an allocation and possibly find the corresponding leak if it is one.
Note that kernel heap leak checking has to be enabled manually by setting the
KERNEL_HEAP_LEAK_CHECK define to 1.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23953 a95241bf-73f2-0310-859d-f6bbb57e9c96
and pages are now kept in lists as well. This allows to return free pages once
a bin does not need them anymore. Partially filled pages are kept in a sorted
linked list so that allocation will always happen on the fullest page - this
favours having full pages and makes it more likely lightly used pages will get
completely empty so they can be returned. Generally this now goes more in the
direction of a slab allocator.
The allocation logic has been extracted, so a heap is now simply attachable to
a region of memory. This allows for multiple heaps and for dynamic growing. In
case the allocator runs out of free pages, an asynchronous growing thread is
notified to create a new area and attach a new heap to it.
By default the kernel heap is now set to 16MB and grows by 8MB each time all
heaps run full.
This should solve quite a few issues, like certain bins just claiming all pages
so that even if there is free space nothing can be allocated. Also it obviously
does aways with filling the heap page by page until it overgrows.
I think this is now a well performing and scalable allocator we can live with
for quite some time. It is well tested under emulation and real hardware and
performs as expected. If problems come up there is an extensive sanity checker
that can be enabled by PARANOID_VALIDATION that covers most aspects of the
allocator. For normal operation this is not necessary though and is therefore
disabled by default.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23939 a95241bf-73f2-0310-859d-f6bbb57e9c96
not use a single static variable to synchronize CPUs at two points. In an
environment where CPUs do not really run concurently (in emulation or with
logical processors) it would be possible for CPUs to get trapped in the first
synchronization while another CPU might just do its thing and change the
sync variable again. These CPUs would then never leave the first loop as the
exit condition has already passed again. The key is to use two different sync
variables like it is done in early kernel initialization. As I didn't manage
to trigger this code though I am not sure if this is gonna work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23926 a95241bf-73f2-0310-859d-f6bbb57e9c96
This is not safe when already freed memory is overwritten. But since we also
store the next pointer of the freelist in there, overwriting would break the
freelist and cause a crash in that case. This gives a drastic performance
boost when freelists grow during use and especially when opening and closing
a lot of programs.
* Optimize filling the freed element with 0xdeadbeef by writing 4 bytes at a
time instead of using single byte writes. Works as all our bins have an
element size that is a multiple of four. Put a panic in there just in case
this assumption isn't met for some reason.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23879 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Stumbled upon a possible bug while trying to understand the reuse of large
allocations. The "first" variable was always set to the current index at the
end of the loop, even if it was already set. This should have caused that
the success condition to never be reached.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23866 a95241bf-73f2-0310-859d-f6bbb57e9c96
When specified it desigantes that the interrupt handler should not lock the
vector with a spinlock when executing the installed interrupt handlers. This
is necessary to allow the same interrupt vector to be handled in parallel on
different CPUs. And it is required for the CPU halt to work synchronously when
there is more than one AP CPU. Though the acquire_spinlock() should cause IPIs
to be processed, only this fixed the SMP_MSG_FLAG_SYNC problem for me.
Not locking is safe as long as it is guaranteed that no interrupt handler is
registered or removed while the interrupt handler is running. We can guarantee
this for the SMP interrupt handlers we install in arch_smp_init() as they are
never uninstalled. Probably this flag should be made private though.
Restored the SMP_MSG_FLAG_SYNC when entering the kernel debugger.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23838 a95241bf-73f2-0310-859d-f6bbb57e9c96
confirmation after sending off the startup IPIs. We simply moved on and setup
the temporary stack address for the next CPU to be started. With this it was
possible that the trampoline code did not manage to load the address before
we overwrote it. So for configurations with more than two CPUs it was possible
that two CPUs were setup to the same kernel stack which could have caused all
sorts of things - most likely a tripple fault and a reboot. On real hardware
this seems very unlikely but it was easily reproducible with QEMU and -smp >2.
We now use the shared trampoline stack to implement a notification mechanism.
The trampoline code will clear the stack location variable once it has loaded
everything it needs from the trampoline stack. On the other side
smp_boot_other_cpus() will wait for this variable to be cleared after it sent
the startup IPIs so that it knows when it can safely move on and overwrite the
area to boot the next CPU.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23800 a95241bf-73f2-0310-859d-f6bbb57e9c96
was a race condition when more than one CPU would enter the debugger at the
same time (or rather before one CPU could stop all the others). We now use the
inDebugger variable to tell if someone is already in the debugger and then
only process inter CPU messages and retry entering the debugger.
Since sending the synchronous broadcast most of the time hung over here with
SMP enabled I removed the synchronous flag and added a simple spin to give the
other CPUs a chance to process the halt request. Added comments that explain
the reasons and a ToDo to revert to synchronous delivery once we fixed the
problem. The kernel debugger is now usable on my quad core.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23751 a95241bf-73f2-0310-859d-f6bbb57e9c96
systems it can easily happen that the thread gets removed from the queue (when
it times out for example) during the time we don't hold the sem lock.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23749 a95241bf-73f2-0310-859d-f6bbb57e9c96
at the end of that loop we guaranteed a crash when this special handling was
triggered.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23748 a95241bf-73f2-0310-859d-f6bbb57e9c96
OS-owned bit. Otherwise we overwrite exactly the bit we later have to wait for.
Could theoretically help on legacy support issues, but I doubt it since most
hardware probably does not even use EHCI legacy support as it's normally not
needed to support full/low-speed input devices.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23747 a95241bf-73f2-0310-859d-f6bbb57e9c96
useful soon so that you can actually do something after entering KDL.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23742 a95241bf-73f2-0310-859d-f6bbb57e9c96
This should be in line with all uses of scheduler_enqueue_in_run_queue() and
simplifies a few places where it is used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23738 a95241bf-73f2-0310-859d-f6bbb57e9c96
controller ownership in EHCI to aid debugging USB legacy support issues.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23735 a95241bf-73f2-0310-859d-f6bbb57e9c96
enqueued into the run_queue again. Modified the workaround to a panic in the
scheduler so we notice when something else does the same.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23731 a95241bf-73f2-0310-859d-f6bbb57e9c96
A thread that just missed a semaphore and put itself into the sems notify
queue could be enqueued into the run queue by release_sem_etc() of another
CPU before the CPU running the thread had a chance to reschedule it. Therefore
there is a timeframe where a thread can be running on one CPU and already be
in the run queue again. In this case no other CPU may schedule this thread
because then it would overwrite the threads' CPU pointer which kills the rest
of the scheduler logic, smp_get_current_cpu() and everything that depends on
that (like the kernel debugger). The more CPUs you have the easier this could
happen, up to the point where it was always triggered during boot on my quad
core system. The system would freeze and you could not enter the kernel
debugger, because two CPUs thought they were the same and disabled each other
through SMP communication. This makes booting my system stable and might fix
the occasional hang on boot for other SMP systems with only 2 CPUs/cores.
I've put a ToDo comment that details this above the workaround. Maybe we
should fix this in another way. Reviews, comments and suggestions welcome ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23721 a95241bf-73f2-0310-859d-f6bbb57e9c96
Notify the finisher thread after canceling transfers. It was possible that freeing the allocated
transfer resources would be delayed unnecessarily until some other transfer completed and woke up
the finisher thread. Found by Salvatore Benedetto, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23714 a95241bf-73f2-0310-859d-f6bbb57e9c96
transfer resources would be delayed unnecessarily until some other transfer completed and woke up
the finisher thread. Found by Salvatore Benedetto, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23713 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refactored everything to C++ with the different devices as subclasses
* Added proper ACM detection with parsing of the ACM descriptors
* Added device transfer error handling and fixed some concurency issues
* Big cleanup to conform to our style guide
This should make at least ACM stable to use. Commiting this over my K850i with
ACM compliant USB modem and UMTS data connection. Note that support for all
other device classes (Prolific, FTDI and KLSI) is untested but should work the
same as before. Note also that since we currently lack a TTY module this will
only build/work for R5 or Dano with the proper TTY headers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23634 a95241bf-73f2-0310-859d-f6bbb57e9c96
any devices anymore it gets unloaded. Also made sure the function pointers
are properly initialized and disabled debug output.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23494 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed wrong start and size used in the runtime_loader
* Fixed off by one error in the matching loop of the cleanup hook
* Make sure we successfully acquire the locking sem of the exit stack
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23493 a95241bf-73f2-0310-859d-f6bbb57e9c96
As (our) gcc unfortunately uses atexit() to clean up lazily initialized static
variables inside functions we have to ensure that we do the right thing with
unloadable shared objects. In case a shared object was unloaded that installed
an atexit() hook the application would crash on exit. We now implement a
callback into libroot that is used to call all the atexit() hooks of a
component that is to be unloaded. Most prominently this fixes the media_server
crash at shutdown.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23486 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Removed now unnecessary devfs calls again
* Add an explanation in device_removed()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23442 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Cache the looked up image symbols as well as the API version in the driver entry
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23441 a95241bf-73f2-0310-859d-f6bbb57e9c96
mix up the resizingMode and flags field in the BView constructor. This does
not cause problems under BeOS but was causing wrong follow modes when those
applications were run under Haiku. In case such an application is detetected
a corresponding warning is printed out. Also added a comment explaining the
rational behind the change and a ToDo for the later cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23424 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Move most of MIME database support out of libbe and into registrar
* Use the (async) MessageDeliverer instead of a synchronous SendMessage in _SendMonitorUpdate
This fixes a deadlock when the message port of a MIME database watching
application gets full as documented in bug #1311.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23423 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Beginnings of devfs interaction to properly publish/unpublish under Haiku
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23412 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Some restructuring and cleanup
This keeps the input_server from polling a removed device continuously.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23388 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Actually enable the periodic schedule so that any interrupts work over EHCI
For those who wait for OHCI: You can now attach your USB 1.1 mouse or keyboard
to a USB 2.0 hub and it should work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23382 a95241bf-73f2-0310-859d-f6bbb57e9c96
Michael Lotz