away cpuid info into the current cpu structure. Trouble was the code was running before the current
thread pointer was set on each cpu, so it was always looking up cpu 0's structure and saving there,
leaving the other ones uninitialized. Surprisingly this works fine on my machine, but obviously fails
on others (cpuid info would have been zeroed probably). Solution is to change the order that things
are brought up on each cpu to set the current thread pointer first. I don't really like that solution
but it'll work for now. Added a comment to the effect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20154 a95241bf-73f2-0310-859d-f6bbb57e9c96
Now two complete tss structures exist within the per-cpu structure. Instead
of having to create a seperate area per each one, initialize them in place.
Also, the old mechanism to getting all of the cpus to get initialized was
subtly broken, but still managed to work. Now, just force all the cpus to
initialize at boot, which makes the actual swapping of esp0 somewhat simpler.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20131 a95241bf-73f2-0310-859d-f6bbb57e9c96
* recursive_lock_unlock() now returns a void to mirror it's counterpart better;
use recursive_lock_get_recursion() if you're interested in the lock depth.
* switch_sem(), and release_sem() now don't do anything anymore in kernel startup
mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20099 a95241bf-73f2-0310-859d-f6bbb57e9c96
containing the Haiku SVN revision number which is used by uname(). The
value is 0 when built, but updated by the build system before copying
libroot to the image (new rule CopySetHaikuRevision).
* For AboutHaiku we no longer write the SVN revision number into a
resource. Instead we use the uname() info.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20082 a95241bf-73f2-0310-859d-f6bbb57e9c96
for one quantum wasn't really a good idea, as this could get quite expensive for the thread
(depending on the system load, it might have taken a long time until the thread was scheduled
again, no matter what priority it was).
Also, calling thread_yield() in a loop would have taken 100% CPU time.
Now, we sort the thread into the queue as with any other thread, but we'll ignore it once.
This now guarantees an actual context switch, as well as a much fairer rescheduling policy
for threads calling that function.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20077 a95241bf-73f2-0310-859d-f6bbb57e9c96
at boot, per cpu, detect the cpu, pull down all the relevant cpuid bits and
save them into the per-cpu structure. Changed most of the code scattered here
and there that reads the cpuid to use a new api, x86_check_feature, which looks
at the saved bits.
Also changed the system_info stuff to read from these bits.
While i was at it, refreshed all the bits to be current.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20072 a95241bf-73f2-0310-859d-f6bbb57e9c96
Replaced the _kern_null syscall with _kern_is_computer_on.
is_computer_on_fire is a bit harder, since it returns a float from kernelland, which
at the moment isn't supported in haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20069 a95241bf-73f2-0310-859d-f6bbb57e9c96
I don't know why (or how) it could work before r19775, though.
This fixes the wrong return code from wait_for_thread() in most cases, and thus,
bug #1011.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20060 a95241bf-73f2-0310-859d-f6bbb57e9c96
does. Marcus, what problem did you encounter?
The BuildPXEstage1 actions use "as" ATM, which is not correct, since it
should actually use the target platform assembler (i.e.
cross-compilation won't work). It should be replaced by $(TARGET_CC),
but that results in the following errors, when compiling with gcc 2.95.3:
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:
Assembler messages:
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:39:
Error: missing ')'
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:96:
Error: `0x6(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:102:
Error: `0xa(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:127:
Error: `2(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:128:
Error: `0(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:147:
Error: `16(%ebx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:149:
Error: `20(%ebx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:173:
Error: `2(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:174:
Error: `0(%edx)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:298:
Error: `(%esi)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:299:
Error: `(%edi)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:306:
Error: `(%esi)' is not a valid 16 bit base/index expression
/home/bonefish/develop/haiku/haiku/src/system/boot/platform/pxe_ia32/pxe_stage1.S:307:
Error: `(%edi)' is not a valid 16 bit base/index expression
For the gcc 4 configuration all but the first errors disappear. It looks
like these are bugs in older assembler version. Any reasonable
work-around?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20043 a95241bf-73f2-0310-859d-f6bbb57e9c96
* we now always flush the TLBs after having unmapped some pages.
* vm_soft_fault() could traverse to a source cache while it was being collapsed
by vm_cache_remove_consumer() - this is now no longer possible as the latter
marks the cache as busy when doing so, and the former now tests this flag and
locks the cache (via the new fault_acquire_locked_source() function).
* if fault_acquire_locked_source() fails with B_BUSY, the current cache is locked
again, and tested again for the page - as it might have been moved upwards to it
with the destruction of its former source.
* The cache delivering the page for vm_soft_fault() is now locked until the end;
it can no longer go away before having actually mapped the page into the area.
* This also fixes the issue where pages would get lost as vm_soft_fault() put the
page in the active list, no matter if its cache still existed.
* Also, we now keep a reference of to a cache in case a dummy page is inserted; this
makes again sure that it doesn't go away during the execution of vm_soft_fault()
(which could even add this page to the free list...).
* divided vm_soft_fault() into several smaller functions which should make it much
more readable.
* Added a "cache_chain" KDL command that dumps the whole chain until the bottom
when giving a pointer to a vm_cache as parameter.
* now usually call vm_cache_acquire_ref() before map_backing_store(), even though
it shouldn't be really needed (I added it for debugging purposes).
* Some minor cleanup.
* NOTE: a major problem still persists: when removing a vm_cache, it's possible
that some of its pages are still mapped, and there is currently no mechanism
to get rid of these mappings! I've added TODO comments into vm_cache.c where
appropriate.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20028 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also prepare uname to return the build SVN revision number,
which will work only if I could figure out how to define it from Jamfile.
Or, better, in build/jam/BuildSetup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20023 a95241bf-73f2-0310-859d-f6bbb57e9c96
The "lookup" option has been removed, there is now a "-p" for a physical address, and
"-v" for a virtual address.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20016 a95241bf-73f2-0310-859d-f6bbb57e9c96
process group. This fixes bug #996.
* As a result, the process group stuff and wait_for_child() got much simpler;
get_death_entry() and update_wait_for_any() could go away completely.
* If a team goes away, all of its children are now "reparented" to the kernel team,
instead of the team's parent - this follows common implementations (and POSIX if
I understand it correctly), but not BeOS anymore. The OpenGroup Base says this
about this topic: "If a parent process terminates without waiting for all of its
child processes to terminate, the remaining child processes shall be assigned a
new parent process ID corresponding to an implementation-defined system process."
* We wait too long in wait_test_4 which at least puts us on par with Linux; see
comment in _user_setpgid().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20010 a95241bf-73f2-0310-859d-f6bbb57e9c96
ECHILD in case it doesn't. This fixes bug #995.
* Added a TODO item for solving bug #996.
* wait_for_child() did not release the team lock and restore interrupts in case
the child you wanted to wait for didn't exist...
* with child > 0, wait_for_child() will now check if its really a child of yours,
and not just in the same process group.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19993 a95241bf-73f2-0310-859d-f6bbb57e9c96
This fixes a possible crashing bug when an application with disconnected descriptors
quits.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19951 a95241bf-73f2-0310-859d-f6bbb57e9c96
We might want to remove it again once we have a replacement for it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19929 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also, the output no longer has the leading "0x" to ease reading.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19906 a95241bf-73f2-0310-859d-f6bbb57e9c96
this fixes bug #227 again (which I recently opened again accidently).
* We actually switched the last consumer's source without having acquired its
lock! This fixes some rare random app crashes as well as potential kernel
crash ("cache to be deleted still has consumers").
* Some more comments to explain why things are done and can be done the way they
are done :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19878 a95241bf-73f2-0310-859d-f6bbb57e9c96
its death entry into the parent team's queue - we need to do this atomically.
As an effect, wait_for_thread() sometimes failed with B_BAD_THREAD_ID.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19808 a95241bf-73f2-0310-859d-f6bbb57e9c96
so that this can be done safely.
It was also needed, as it would call vm_cache_release_ref() on failure which requires you
to have no vm_cache_ref locks around (as it might deadlock in this case).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19806 a95241bf-73f2-0310-859d-f6bbb57e9c96
had the cache_ref locked, it also locked two refs in the wrong order (bottom-up);
there was even a TODO item for this...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19801 a95241bf-73f2-0310-859d-f6bbb57e9c96
* "sc"/"where"/"bt" now prints the area where the function of the stack frame
is located in case there is no other information (using the above function).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19800 a95241bf-73f2-0310-859d-f6bbb57e9c96
* even worse, in case of fork(), it was never initialized.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19799 a95241bf-73f2-0310-859d-f6bbb57e9c96
two cache_refs - it needs to count the consumers of the lower cache to find
its actual number of references; the upper cache could still be in use by
someone else.
* There were several locking bugs in the VM code; since cache_ref::cache can
change, we must not access it without having the cache_ref locked.
* As a result, map_backing_store() now requires you to have the lock of the
store's cache_ref held.
* And therefore, some functions in vm_cache.c must no longer lock the cache_ref
on their own, but require the caller to have it locked already.
* Added the -s option to the cache/cache_ref KDL commands: it will only print
the requested structure, and not its counterpart (useful if accessing one
structure results in a page fault, as was possible previously).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19796 a95241bf-73f2-0310-859d-f6bbb57e9c96
waiting for in case it was interrupted; but that could easily lead the thread_exit()
function to access invalid memory (and thus, crash the kernel): since we could not
remove our death entry from the thread, we have to make sure the thread (which might
still run even if not in the thread hash anymore) will access our death entry as
long as it is valid. IOW we must wait for the thread to delete its exit semaphore,
even if we were interrupted before.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19790 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed dumping the area list of a cache I broke with the previous commit.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19789 a95241bf-73f2-0310-859d-f6bbb57e9c96
(you can still use both commands, but you'll see always the same output).
* The cache_ref's area list now also prints the owner of the area.
* Added "-p" option to "cache"/"cache_ref" that will show the pages of the cache; if you
omit it, it will now only present you a page counter.
* Nicer output for the commands above.
* Added "dl" to display memory in 64 bit values.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19787 a95241bf-73f2-0310-859d-f6bbb57e9c96
* send_signal_etc() (among others) used team::main_thread in an unsafe way; it is
possible for a team to be part of the team list and a group without having
a main thread very early in its creation process.
* Replaced most occurences of team->main_thread->id with team->id since the team
always inherits the ID of its main thread in Haiku for quite some time now.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19781 a95241bf-73f2-0310-859d-f6bbb57e9c96
Travis Geiselbrecht