Haha you mean just like a yellow guru meditation? 
Hangs!! Oh shit remembers me OS/2 warp deadlocking completely hang on my 486.
Besides that i have app_server on White and black screen continúe It hangs. But when loading normally. The strange IS the system was running fine. I don’t know what happened there
I seem to have a different issue, no crash but just intermittent locks, and even using the fallback graphics driver doesn’t solve the problem completely (but it seems to improve the situation).
It’s best triggered by browsing through the SlowMenus in Deskbar (I always noticed some extra lag when switching between menus, but that was different).
I will build an ISO with the patch provided by @waddlesplash and see if I can get some useful info from it.
Would be important to fix this before beta 5 is released, I think.
I have intermittent (long and annoying) locks when using Haiku in a Virtual Machine.
In baremetal I have a noisy (it fills my syslog) error with usb (that sometimes made me loose keyboard operativity, but not lately)
At shutdown KDL shows up and I need to launch reboot command 
The VM bug I experience does not show up at boot time as some tracked bugs in Haiku development Tracker but it seems related to writings on disc or often happened when using git.
For the latter I’ll gather the data this night and open a Ticket
1 Like
ok finally building this now and will write my results later, updating this post.
hmmm switched to your branch but can’t get the nightly or regular to compile:
...failed BootLd generated/objects/haiku/x86_64/release/system/boot/bios_ia32/boot_loader_bios_ia32
full log of affected compile phase:
ld: generated/objects/haiku/x86_64/release/system/boot/bios_ia32/boot_libroot_bios_ia32.o: in function `number(Buffer&, unsigned long long, unsigned long, int, int, int)':
kernel_vsprintf.cpp:(.text+0x9f5): undefined reference to `__udivmoddi4'
ld: generated/objects/haiku/x86_64/release/system/boot/bios_ia32/boot_libroot_bios_ia32.o: in function `vsnprintf':
(.text+0xe21): undefined reference to `__umoddi3'
ld: (.text+0xeb6): undefined reference to `__udivmoddi4'
ld: (.text+0xf62): undefined reference to `__udivmoddi4'
ld -m elf_i386_haiku -Bstatic -m elf_i386_haiku --script=./src/system/ldscripts/x86_64/boot_loader_bios_ia32.ld -o "generated/objects/haiku/x86_64/release/system/boot/bios_ia32/boot_loader_bios_ia32" "generated/objects/haiku/x86_64/release/system/boot/platform/bios_ia32/bios_ia32/boot_platform_bios_ia32.o" "generated/objects/haiku/x86_64/release/system/boot/arch/x86/bios_ia32/boot_arch_x86_64.o" "generated/objects/haiku/x86_64/release/system/boot/loader/bios_ia32/boot_loader.a" "generated/objects/haiku/x86_64/release/system/boot/loader/net/bios_ia32/boot_net.a" "generated/objects/haiku/x86_64/release/system/boot/loader/bios_ia32/boot_partitions.a" "generated/objects/haiku/x86_64/release/system/boot/loader/file_systems/bfs/bios_ia32/boot_bfs.a" "generated/objects/haiku/x86_64/release/system/boot/loader/file_systems/amiga_ffs/bios_ia32/boot_amiga_ffs.a" "generated/objects/haiku/x86_64/release/system/boot/loader/file_systems/tarfs/bios_ia32/boot_tarfs.a" "generated/objects/haiku/x86_64/release/system/boot/loader/file_systems/fat/bios_ia32/boot_fatfs.a" "generated/objects/haiku/x86_64/release/system/boot/loader/file_systems/packagefs/bios_ia32/boot_packagefs.a" "generated/objects/haiku/x86_64/release/system/boot/loader/bios_ia32/boot_loader.a" "generated/objects/haiku/x86_64/release/system/boot/libs/bios_ia32/boot_zlib.a" "generated/objects/haiku/x86_64/release/system/boot/libs/bios_ia32/boot_zstd.a" "generated/objects/haiku/x86_64/release/system/boot/bios_ia32/boot_libroot_bios_ia32.o" /boot/system/develop/lib/libsupc++.a /boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/13.3.0/libgcc.a \
...failed BootLd generated/objects/haiku/x86_64/release/system/boot/bios_ia32/boot_loader_bios_ia32 ...
BUILD FAILURE:
...failed updating 1 target(s)...
...skipped 5 target(s)...
...updated 460 target(s)...
You can’t build the 32-bit bootloader on x86_64 without crosstools. You’ll need to disable building of the bootloaders by commenting out a line in the build scripts:
diff --git a/build/jam/packages/Haiku b/build/jam/packages/Haiku
index c474aa503a..b3649a14f8 100644
--- a/build/jam/packages/Haiku
+++ b/build/jam/packages/Haiku
@@ -18,7 +18,7 @@ for driver in $(SYSTEM_ADD_ONS_DRIVERS_NET) {
# bootloaders
local bootTarget ;
for bootTarget in $(HAIKU_BOOT_TARGETS) {
- AddFilesToPackage data platform_loaders : haiku_loader.$(bootTarget) ;
+# AddFilesToPackage data platform_loaders : haiku_loader.$(bootTarget) ;
}
# modules
Yes I also suspected thus, but even changing that line and doing a
./configure --target-arch x86_64
didn’t help
here is another screenshots with using safe mode graphics driver, which improves the situation significantly but does not fully solve it.
And as for the USB issue @TmTFx noticed, I also have some issues with my external USB touchpad (since the built-in doesn’t work on my Laptop, but it’s anyway behaving strange now, even under Linux).
Sometimes on boot or when closing the laptop lid and later returning to the session, it won’t react.
I have to unplug and plug it in again, even then it takes quite a while (up to 10s or such) to reconnect.
Sometimes I even have to restart input_server.
So back to the original issue, I notice there are a lot of “gone” teams (the black bar is sometimes much higher than on this screenshot)… also notice the high kernel load, even though no CPU intensive process is running. Is this normal? I know about the “idle” teams, but still looks strange…
Did you build just haiku.hpkg haiku_devel.hpkg? The full image always need the loaders of course.
Yes, that does look strange. I’m not sure what might be causing it though.
Meanwhile I tested with my asserts patch again and managed to reproduce a problem, so hold off on testing with it for now as you’ll likely just hit asserts on boot as I did…
2 Likes
I started a full nightly build from the Haiku source root…
Ok will wait then, and great you could reproduce the issue at least partially!
Well, unfortunately it happened only once… I just rebuilt with even more assertions to try and catch it earlier but now it doesn’t seem to happen again. I’ll see if I can get it to recur…
Just upgraded to Haiku beta 5 master and it seems a lot more responsive and I didn’t experience lags so far, but I didn’t yet test thoroughly, just a first impression.
Yes, I reverted the change from July 19th that was presumably causing the slowness, so it should be.
3 Likes
Hi.
Seems like haiku does not want CSM disabled in BIOS and that makes a Crash relevant at least in the radeon_hd driver. Enabling It , boots okay to the Desktop.
I haven’t seen the problem again. Here’s a revised assertions change, please compile & test with it and see if it catches the problem for you:
1 Like
@grexe, did you have any chance to test this? Did any of the asserts trip?
I’m sorry I didn’t have a chance to test this yet and will be away from my computer for 2 days but will do so for sure by the end of this week.
1 Like
OK, very good. In the meantime I revised the asserts patch again, here’s the latest version:
2 Likes
sorry for the late reply, was quite busy with dog- and daughter sitting,-)
I tried to compile the packages but got another error:
BUILD FAILURE:
...failed updating 1 target(s)...
...skipped 2 target(s)...
BuildHaikuPackage1 generated/objects/haiku/x86_64/packaging/packages/haiku_devel.hpkg
haiku_devel.hpkg: Removing and re-creating package contents dir ...
haiku_devel.hpkg: Collecting package contents ...
haiku_devel.hpkg: mimeset'ing package contents ...
haiku_devel.hpkg: Creating the package ...
Error: Failed to open package info file "generated/objects/haiku/x86_64/packaging/packages_build/regular/hpkg_-haiku_devel.hpkg/haiku_devel-package-info": No such file or directory
build/scripts/build_haiku_package "generated/objects/haiku/x86_64/packaging/packages/haiku_devel.hpkg" "generated/objects/haiku/x86_64/packaging/packages_build/regular/hpkg_-haiku_devel.hpkg/haiku_devel-package-info" generated/objects/haiku/x86_64/packaging/packages_build/regular/hpkg_-haiku_devel.hpkg/scripts/haiku.package-init-vars generated/objects/haiku/x86_64/packaging/packages_build/regular/hpkg_-haiku_devel.hpkg/scripts/haiku.package-make-dirs generated/objects/haiku/x86_64/packaging/packages_build/regular/hpkg_-haiku_devel.hpkg/scripts/haiku.package-copy-files generated/objects/haiku/x86_64/packaging/packages_build/regular/hpkg_-haiku_devel.hpkg/scripts/haiku.package-extract-files
...failed BuildHaikuPackage1 generated/objects/haiku/x86_64/packaging/packages/haiku_devel.hpkg ...
BUILD FAILURE:
...failed updating 1 target(s)...
Then I tried to compile to a native separate Haiku partition but ran into the ia32 error again, as it tries to install a boot loader.
How can I specify to only install a x86_64 or even EFI bootloader?
Also, the build script assumes a HAIKU_REV to be set and fails the entire build if not - couldn’t it default to the git revision or such?
DetermineHaikuRevision1 generated/build/haiku-revision
fatal: No names found, cannot describe anything.
Error: you are using a Haiku clone without tags, please set
the revision tag to use (e.g. HAIKU_REVISION=hrev43210)
./build/scripts/determine_haiku_revision . generated/build/haiku-revision
...failed DetermineHaikuRevision1 generated/build/haiku-revision ...
...removing generated/build/haiku-revision
BUILD FAILURE:
...failed updating 1 target(s)...
...skipped 5 target(s)...
...updated 295 target(s)...
Not the git revision, but “or such”. It uses the last tag + number of commits, but your clone doesn’t have tags, thus the error. Use git fetch --tags to get them. If you cloned from github, you would have to add another remote ( https://review.haiku-os.org/haiku) and fetch them from there.
1 Like