"now", and given expected results).
* Now only prints failures, unless you give a command argument (which just
enables verbose output).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32121 a95241bf-73f2-0310-859d-f6bbb57e9c96
interrupts when invoking it. The user TLB invalidation function essentially only
reads and writes back control register 3 (cr3) which holds the physical address
of the current page directory. Still a preemption between the read and the write
can cause problems when the last thread of a team dies and therefore the team
is deleted. The context switch on preemption would decrement the refcount of the
object that holds the page directory. Then the team address space is deleted
causing the context switch returning to that thread to not re-acquire a
reference to the object. At that point the page directory as set in cr3 is the
one of the previously run thread (which is fine, as all share the kernel space
mappings we need). Now when the preempted thread continues though, it would
overwrite cr3 with the physical page directory address from before the context
switch still stored in eax, therefore setting the page directory to the one of
the dying thread that now doesn't have the corresponding reference. Further
progressing the thread would release the last reference causing the deletion
of the object and freeing of the, now active again, page directory. The memory
getting overwritten (by deadbeef) now completely corrupts the page directory
causing basically any memory access to fault, in the end resulting in a
triplefault. This should fix bug #3399.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32118 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Now uses g++ instead of gcc for C++ files.
* Removed mwcc support.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32113 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Replaced Pe GCC4 package with one that works again after the BToolTip
addition.
* Disabled Firefox and Vision GCC4 packages for the time being, so that one
at least gets a working hybrid installation.
* Added Clockwerk GCC2 and GCC4 packages. I also added it to the alpha
release build profile, so that people testing the pre-alpha images have
more easy access to it. I am not sure if it should stay there, since it may
not be polished enough. Feedback welcome! :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32112 a95241bf-73f2-0310-859d-f6bbb57e9c96
again. Should fix playback of any file where the ffmpeg plugin was responsible
for sound. (The symptoms were a crash into the debugger because of an unspecified
audio format...)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32107 a95241bf-73f2-0310-859d-f6bbb57e9c96
Is it intentional that Horizontal Frequency is reported as being KHz while
Vertical Frequency is reported as being Hz?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32104 a95241bf-73f2-0310-859d-f6bbb57e9c96
didn't own.
* We are supposed to open the AVCodecContext in the writer, even though we never
use it. According to libav-users mailing list, this is necessary, since that
will allocate and initialize some structures that are later needed in
av_write_header(). How this is supposed to work for encoders that libavcodec
does not support, or which we don't know how to map, I do not yet know. For
now it doesn't matter and resolves the problem that audio tracks report the
wrong stream duration.
* Some more improvements with regards to what information we need to fill out
and which we don't.
* Use more sensible defaults for the stream bitrate, so that we get better
quality video by default. This and other parameters can be calculated when
we implement setting the quality.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32103 a95241bf-73f2-0310-859d-f6bbb57e9c96
* when items are removed, the anchor may need adjustment (fixes the problem
in Beam reported by Stippi)
* the check for needed adjustment of fLastSelected in _Select(from, to, extend)
was broken, as it needs to be independent of fFirstSelected - this fixes
broken navigation after doing a select-all
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32099 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Don't leak the driver settings handle.
* No need to get the "active" parameter in ValidateCreateChild() -- either
way is fine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32098 a95241bf-73f2-0310-859d-f6bbb57e9c96
editor, when they don't have any additional parameters to edit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32096 a95241bf-73f2-0310-859d-f6bbb57e9c96
disk device to the locking functions, not only the ID of the disk device
itself.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32094 a95241bf-73f2-0310-859d-f6bbb57e9c96
* avoid setting fAnchorIndex multiple times in certain situations
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32090 a95241bf-73f2-0310-859d-f6bbb57e9c96
in the handler, instead of checking if the window is an offscreen one,
check if fDirectWindowData is NULL, and do nothing if it's the case.
When setting a clip region in ServerPicture, also invalidate the clipping.
To do so, I added a public ServerWindoow::UpdateCurrentDrawingRegion()
which just calls the private function. Please review and see if it can
be done better. This fixes the problem with BPicture and the
ConstrainClippingRegion() op (see ticket #1389)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32087 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added a -s option to get the string value of the setting directly instead of interpreting it as bool.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32086 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The BView API can probably be regarded as good enough; the implementation
might need to be improved over time (also, some things as archivability
aren't fully implemented yet). The ToolTip.h header should get public once
finalized.
* Added new B_MOUSE_IDLE message that is sent to a BView after a certain
time has passed (BToolTipManager::ShowDelay()).
* Added small test app (ToolTipTest) that shows what is already working.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32078 a95241bf-73f2-0310-859d-f6bbb57e9c96
else this won't work as is (this is something that could be done, better,
though).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32077 a95241bf-73f2-0310-859d-f6bbb57e9c96
- added some multiboot support code:
- dump some of the passed info,
- parse command line (skip the 'kernel' name and pass the rest to stage2_args.arguments),
- added an add_stage2_driver_settings() function which takes stage2_args.arguments and translates it into safe mode driver settings, a bit dumb for now.
This allows using qemu -kernel haiku_loader -append 'debug_screen true' and get debug output without having to enter the menu (once multiboot info is used to determine the boot device too).
The idea is to allow passing driver settings and using them to pass extra stuff (like 'force_keymap fr' and other stuff for demo), and to help automate tests ('run_test /bin/sometest').
This should answer Axel's question :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32076 a95241bf-73f2-0310-859d-f6bbb57e9c96
needed to show all of the text view's contents. No idea what the previous
solution was about.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32075 a95241bf-73f2-0310-859d-f6bbb57e9c96
allow for more parallelism. Also introduce seperate locks for the bins and
for page allocation. This greatly reduces lock contention and reduces the
duration the locks are held due to them overall protecting less code. Now only
allocations of the same size hitting the same allocator or allocating larger
chunks of memory should block. Previously, basically any allocation and also
free would be mutually exclusive, making it scale pretty badely.
* Added memalign_nogrow(). As it uses heap_memalign() anyway, there's no real
reason not to allow for an alignment.
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32074 a95241bf-73f2-0310-859d-f6bbb57e9c96
ROUNDUP to use '*' and '/' -- the compiler will optimize that for powers of
two anyway and this implementation works for other numbers as well.
* The thread::fault_handler use in C[++] code was broken with gcc 4. At least
when other functions were invoked. Trying to trick the compiler wasn't a
particularly good idea anyway, since the next compiler version could break
the trick again. So the general policy is to use the fault handlers only in
assembly code where we have full control. Changed that for x86 (save for the
vm86 mode, which has a similar mechanism), but not for the other
architectures.
* Introduced fault_handler, fault_handler_stack_pointer, and fault_jump_buffer
fields in the cpu_ent structure, which must be used instead of
thread::fault_handler in the kernel debugger. Consequently user_memcpy() must
not be used in the kernel debugger either. Introduced a debug_memcpy()
instead.
* Introduced debug_call_with_fault_handler() function which calls a function
in a setjmp() and fault handler context. The architecture specific backend
arch_debug_call_with_fault_handler() has only been implemented for x86 yet.
* Introduced debug_is_kernel_memory_accessible() for use in the kernel
debugger. It determines whether a range of memory can be accessed in the
way specified. The architecture specific back end
arch_vm_translation_map_is_kernel_page_accessible() has only been implemented
for x86 yet.
* Added arch_debug_unset_current_thread() (only implemented for x86) to unset
the current thread pointer in the kernel debugger. When entering the kernel
debugger we do some basic sanity checks of the currently set thread structure
and unset it, if they fail. This allows certain commands (most importantly
the stack trace command) to avoid accessing the thread structure.
* x86: When handling a double fault, we do now install a special handler for
page faults. This allows us to gracefully catch faulting commands, even if
e.g. the thread structure is toast.
We are now in much better shape to deal with double faults. Hopefully avoiding
the triple faults that some people have been experiencing on their hardware
and ideally even allowing to use the kernel debugger normally.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32073 a95241bf-73f2-0310-859d-f6bbb57e9c96
