that causes a locking order reversal (condition variable lock <-> system
profiler lock) and thus a potential deadlock. Instead we use the thread
blocking API directly. Fixes #5229.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35003 a95241bf-73f2-0310-859d-f6bbb57e9c96
even if it meant displaying the same label twice.
Fixes bug #5233.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35002 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Show Alert when bluetooth_server is not running (work in progress)
- Typos and Style
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34997 a95241bf-73f2-0310-859d-f6bbb57e9c96
I had to uptade the catkeys as Travis tool has trouble keeping up with changes in the repository (most importantly, cpufrequency fixes and mail sentance casing). I hope nothing was lost in the process.
Travis, if you read this, I had to load the catkey files in vim and save them back to get them linked correctly by the buildtools. I suspect some line ending problem or something alike. Also, your fingerprint computation seemed wrong in most cases.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34994 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Haiku doesn't like the ethernet maximal frame size to be set to 0. This drops the CPU usage and some calls to read/write are now occuring.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34993 a95241bf-73f2-0310-859d-f6bbb57e9c96
only -jN and gcc's build system has problems with multiple jobs. It works
fine for binutils and gcc 4 though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34990 a95241bf-73f2-0310-859d-f6bbb57e9c96
default address of the outgoing interface as a side-effect
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34989 a95241bf-73f2-0310-859d-f6bbb57e9c96
exposes a problem in our UDP-connect implementation: the local address is
not set as a side-effect of connecting to a specific destination.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34987 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Hack StatusView.cpp so it generates a proper catkey file
- StatusView archive constructor wasn't instanciating the catalog
Sync all the cpufrequency catalogs to the current strings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34984 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added parsing for DQue, DQTi, DQSz, DQMi tags. This could be used to check if an application is actually installed.
* added parsing for PtcI (unknown use).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34981 a95241bf-73f2-0310-859d-f6bbb57e9c96
We can only access the page, if it is not busy. Fixes #5228.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34980 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Various smaller fixes.
* Used add_debugger_command_etc() and added more verbose usage message.
* Added option "-m" which iterates through all address spaces and finds out
which virtual pages are mapped to the page.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34979 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added Debug{First,Next}() methods to allow easy iteration through the
address spaces in kernel debugger commands.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34978 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
LockAllSourceCaches()) and moved it to the beginning of the file.
* Removed sMappingLock and adjusted the locking policy for mapping/unmapping
pages: Since holding the lock of the affected pages' caches is already
required, that does now protect the page's mappings, too. The area mappings
are protected by the translation map lock, which we always acquire anyway
when mapping, unmapping, or looking up mappings.
The change results in a -j8 Haiku image build speedup of almost 10%. The
total kernel time drops almost 30%.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34965 a95241bf-73f2-0310-859d-f6bbb57e9c96
Apparently (at least when running in VMware >=2) the boot loader can still
map the same physical page more than once -- in the ACPI or HPET code I
suppose -- which would lead to this situation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34954 a95241bf-73f2-0310-859d-f6bbb57e9c96
