http://cia.vc/stats/author/geist37 git-notify script for CIA haiku haiku master hrev43246 geist [build][OSX] revise the darwin test to darwin10 and darwin11, not a wildcard As PulkoMandy pointed out on IRC, darwin10 and 11 (10.6 and 10.7) are at least partially 64bit, so the test only applies there. When darwin12 comes out it'll have to be fixed. http://cgit.haiku-os.org/haiku/commit/?id=6c6edeb 1321133116 git-notify script for CIA haiku haiku master hrev43245 geist Fix build on OSX Lion, which has apparently bumped the darwin version to darwin11 http://cgit.haiku-os.org/haiku/commit/?id=b2916b0 1321131670 Python Subversion client for CIA1.15OpenBeOS37108geistSMP: remove the tracking of apic id -> cpu id. Don't pass between bootloader and kernel. Kernel doesn't use it, and it could be regenerated in the kernel if it did need it. This also unlocks the apic range the bios can use. Previously the apic ids would have to fit within 0..MAX_CPUS or it'd reject the cpu. Some boxes (mine in particular) seem to sparsely populate the apic id so that the range is pretty large. 90haiku/trunk/headers/private/kernel/arch/x86/arch_kernel_args.hhaiku/trunk/src/system/boot/platform/bios_ia32/smp.cpphaiku/trunk/src/system/kernel/arch/x86/arch_smp.cpp1276304515Python Subversion client for CIA1.15OpenBeOS36836geistBOOT SMP: allow systems with a large number of cpus and/or sparse apic ids to actually boot The old mechanism to route an apic id back to a cpu id is faulty, built with the assumption that the bios will 'pack' the apic ids from 0-num_cpus. In systems that dont do that, the code would randomly corrupt the bootloader. Fatal in this case. This quick fix simply rejects all apic ids >= MAX_CPUS (8). No way it would have worked before if you had a box that started with >= 8 or anything, so it shouldn't regress any existing system. Better solution is to allow any apic id to exist (0-255). On this particular box the ids (from lunix dmesg): SRAT: PXM 0 -> APIC 0 -> Node 0 SRAT: PXM 1 -> APIC 16 -> Node 1 SRAT: PXM 0 -> APIC 2 -> Node 0 SRAT: PXM 0 -> APIC 4 -> Node 0 SRAT: PXM 0 -> APIC 6 -> Node 0 SRAT: PXM 1 -> APIC 18 -> Node 1 SRAT: PXM 1 -> APIC 20 -> Node 1 SRAT: PXM 1 -> APIC 22 -> Node 1 SRAT: PXM 0 -> APIC 1 -> Node 0 SRAT: PXM 0 -> APIC 3 -> Node 0 SRAT: PXM 0 -> APIC 5 -> Node 0 SRAT: PXM 0 -> APIC 7 -> Node 0 SRAT: PXM 1 -> APIC 17 -> Node 1 SRAT: PXM 1 -> APIC 19 -> Node 1 SRAT: PXM 1 -> APIC 21 -> Node 1 SRAT: PXM 1 -> APIC 23 -> Node 1 32haiku/trunk/src/system/boot/platform/bios_ia32/smp.cpp1274068044Python Subversion client for CIA1.15OpenBeOS33192geistFix the CopySetHaikuRevision1 rule if you're building in a plain git repository, not mirroed via git-svn. Calling git-svn on a plain repository seems to cause it to go haywire. 15haiku/trunk/build/jam/FileRules1253391592Python Subversion client for CIA1.15OpenBeOS21477geistre-enable kernel asserts. Disabled by default, but all kernel devs are *highly* recommended to turn them on for your builds and see if it trips anything, and then fix it. 92haiku/trunk/headers/private/kernel/debug.hhaiku/trunk/headers/private/kernel/lock.hhaiku/trunk/src/system/kernel/heap.c1182404268Python Subversion client for CIA1.15OpenBeOS21476geistFix a bug that was tripping an assert in the kernel module code. When iterating through modules, the iterator was loading the module file, inserting it into the module image hash. Then, the first time get_module() was called on a module contained in the image, it was trying to load the image again. It probably actually was. Changed the logic to call get_module_image() which checks to see if it's already loaded. 51haiku/trunk/src/system/kernel/module.cpp1182402439Python Subversion client for CIA1.15OpenBeOS21423geistsome make system work to get x86-64 linux compiles working: -The biggest problem with linking host libraries (libbe_build and libroot_build) was not having the source files compiled with the -fPIC flag. As far as I can tell, we want to do this on all of the other host platforms as well, so hacked the jam files a bit to add it. Forgive me if I've committed more Jamfile sins. 122haiku/trunk/build/jam/BuildSetuphaiku/trunk/build/jam/MainBuildRuleshaiku/trunk/src/build/libbe/app/Jamfilehaiku/trunk/src/build/libbe/interface/Jamfilehaiku/trunk/src/build/libbe/storage/Jamfilehaiku/trunk/src/build/libbe/support/Jamfile1182023035Python Subversion client for CIA1.15OpenBeOS21407geistfix the build on darwin: -fs_shell was using weak aliases, which is apparently not supported on the darwin toolchain (or it's supported in some different way) -remove building strl* routines for some of the host tools, since that already exists in libSystem 77haiku/trunk/src/build/libroot/Jamfilehaiku/trunk/src/tools/fs_shell/driver_settings.cpphaiku/trunk/src/tools/rc/Jamfile1181798283Python Subversion client for CIA1.15OpenBeOS20732geistset the function attribute on the asm memcpy. This should fix the loader problem some folks were seeing on beos binaries. 19haiku/trunk/src/system/libroot/posix/string/arch/x86/arch_string.S1176783587Python Subversion client for CIA1.15OpenBeOS20723geistasm optimized user_memcpy(), which should help somewhat, since the old version was a byte-by-byte copy. 121haiku/trunk/src/system/kernel/arch/x86/arch_cpu.chaiku/trunk/src/system/kernel/arch/x86/arch_x86.Shaiku/trunk/src/system/kernel/vm/vm.cpp1176706119Python Subversion client for CIA1.15OpenBeOS20722geistTurn the assembly optimized memcpy (simple rep movsd) back on for x86. Had to hack around the make system a bit, and the result is pretty nasty, specifically due to the amount of places in the system where various targets poke their fingers into the libroot directory. The solution is less than optimal, but should work for now. 261haiku/trunk/src/system/boot/Jamfilehaiku/trunk/src/system/kernel/Jamfilehaiku/trunk/src/system/kernel/lib/Jamfilehaiku/trunk/src/system/libroot/Jamfilehaiku/trunk/src/system/libroot/posix/string/Jamfilehaiku/trunk/src/system/libroot/posix/string/arch/ppc/arch_string.Shaiku/trunk/src/system/libroot/posix/string/arch/ppc/libc.mkhaiku/trunk/src/system/libroot/posix/string/arch/sh4/arch_string.Shaiku/trunk/src/system/libroot/posix/string/arch/sh4/libc.mkhaiku/trunk/src/system/libroot/posix/string/arch/x86/arch_string.Shaiku/trunk/src/system/libroot/posix/string/arch/x86/memcpy.Shaiku/trunk/src/system/libroot/posix/string/memcpy.chaiku/trunk/src/system/runtime_loader/Jamfile1176704275Python Subversion client for CIA1.15OpenBeOS20720geistfix a bug in _exit() that called the _IO_cleanup routine as if it was a function pointer, which it isn't. The mistake was probably made because there appears to be multiple stdio implementations in the tree (BSD and glibc) so it's easy to look at the wrong code. Perhaps we should clean that up. 17haiku/trunk/src/system/libroot/posix/unistd/_exit.c1176693650Python Subversion client for CIA1.15OpenBeOS20269geistthis seems to solve the 'lock up on bootup on core 2' problem. Basically, there was a pretty subtle race between the cpus in main where if the main cpu released the AP cpus and then before the AP cpus had a chance to run the boot cpu started creating the main thread (which causes smp ici messages to be created) the system would livelock, where the boot cpu waited forever for the AP cpu to acknowledge the ICI (for a TLB flush when creating the kernel stack). Added smp_cpu_rendezvous(), used to synchronize all the cpus to a particular point, and used it a few times in main(). While i was at it i fixed another race that'll probably never happen, but what the hey. Make sure the kernel args are copied into kernel space by the main cpu before letting any other ones use it. 225haiku/trunk/headers/private/kernel/smp.hhaiku/trunk/src/system/kernel/main.chaiku/trunk/src/system/kernel/smp.chaiku/trunk/src/system/kernel/thread.c1172736570Python Subversion client for CIA1.15OpenBeOS20268geistthe last smp change wasn't quite it. This time, make sure it maps the right physical page. 26haiku/trunk/src/system/kernel/arch/x86/arch_smp.c1172735385Python Subversion client for CIA1.15OpenBeOS20265geistthe recent vm change uncovered a long standing latent pseudo-bug where the local and ioapic memory window were mapped into kernel space via create_area(), not map_physical_memory() like it should be. create_area() used to work fine, but now it's a big more picky about mapping memory it can't get a vm_page to (like stuff outside the range of RAM). 21haiku/trunk/src/system/kernel/arch/x86/arch_smp.c1172730617Python Subversion client for CIA1.15OpenBeOS20227geistWhen building binutils, build without -Werror. This was causing failures on my linux box due to silly warnings in binutils code. 15haiku/trunk/build/scripts/build_cross_tools1172387205Python Subversion client for CIA1.15OpenBeOS20162geistfix a kernel clobberer that showed up when running gcc. Was able to successfully build a hello world app with gcc after this. The kernel arg logic was faulty, and wasn't using strlcpy properly (which returns the size of the src string, not the remaining size). Replaced it with a simpler, but less efficient series of strlcat()s. 34haiku/trunk/src/system/kernel/team.c1171868260Python Subversion client for CIA1.15OpenBeOS20161geistinitial support for a commpage, which is a chunk of memory in high kernel space with user readonly permissions. The first use is to let the kernel decide what the preferred syscall mechanism is at boot time and copy the appropriate user space code there. Can be used for routines the kernel can decide best how to use (memcpy, some timing routines, etc). 230haiku/trunk/headers/os/kernel/arch/haiku/trunk/headers/os/kernel/arch/x86/haiku/trunk/headers/os/kernel/arch/x86/commpage.hhaiku/trunk/headers/private/kernel/arch/x86/commpage.hhaiku/trunk/src/system/kernel/arch/x86/Jamfilehaiku/trunk/src/system/kernel/arch/x86/arch_cpu.chaiku/trunk/src/system/kernel/arch/x86/commpage.chaiku/trunk/src/system/kernel/arch/x86/syscall.Shaiku/trunk/src/system/libroot/os/arch/x86/syscalls.inc1171845166Python Subversion client for CIA1.15OpenBeOS20160geistyet another fix for #1018, which has at this point blossomed into a reorg of how AP cpus are initialized. the new cpuid stuff was apparently exacerbating an existing problem where various bits of low level cpu code (specifically get_current_cpu) weren't really initialized before being used. Changed the order to set up a fake set of threads to point each cpu at really early in boot to make sure that at all points in code it can get the current 'thread' and thus the current cpu. A probably better solution would be to have dr3 point to the current cpu which would then point to the current thread, but that has a race condition that would require an int disable, etc. 579haiku/trunk/headers/build/os/drivers/KernelExport.hhaiku/trunk/headers/os/drivers/KernelExport.hhaiku/trunk/headers/private/kernel/arch/cpu.hhaiku/trunk/headers/private/kernel/cpu.hhaiku/trunk/headers/private/kernel/thread.hhaiku/trunk/src/system/kernel/arch/ppc/arch_cpu.cpphaiku/trunk/src/system/kernel/arch/x86/arch_cpu.chaiku/trunk/src/system/kernel/cpu.chaiku/trunk/src/system/kernel/main.chaiku/trunk/src/system/kernel/smp.chaiku/trunk/src/system/kernel/thread.c1171843891