Latest Bugs & Tasks
Please look out for older tickets. This one is a duplicate of #8979 that you reported a few months ago :-)
Also, please always include the original KDL message. If it is scrolled out of sight, you can use the message command to let KDL print it again.
i got the following KDL. So far I see and unstand it is caused by libbe.so or the Haiku-OS kernel.
stack trace for thread 199 "w:124:/boot/home/Desktop" kernel stack: 0x81baf000 to 0x81bb3000 user stack: 0x7067c000 to 0x706bc000 frame caller <image>:function + offset 0 81bb2b58 (+ 48) 80095238 <kernel_x86> invoke_command_trampoline( [34m0x81bb2bf0 [0m) + 0x1c 1 81bb2b88 (+ 12) 80123f32 <kernel_x86> arch_debug_call_with_fault_handler + 0x1b 2 81bb2b94 (+ 48) 800941b2 <kernel_x86> debug_call_with_fault_handler + 0x5e 3 81bb2bc4 (+ 64) 80095491 <kernel_x86> invoke_debugger_command + 0xb9 4 81bb2c04 (+ 64) 800952bd <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: [34m0xcce38030 [0m, int32: [34m0 [0m, [34m0x0 [0m [31m"<NULL>" [0m) + 0x79 5 81bb2c44 (+ 64) 800955fc <kernel_x86> invoke_debugger_command_pipe + 0x9c 6 81bb2c84 (+ 48) 80097298 <kernel_x86> ExpressionParser< [32m0x81bb2d34 [0m>::_ParseCommandPipe( [34m0x81bb2d30 [0m) + 0x234 7 81bb2cb4 (+ 64) 800964b8 <kernel_x86> ExpressionParser< [32m0x81bb2d34 [0m>::EvaluateCommand( [34m0x801a2f60 [0m [36m"sc | qrappend" [0m, [34m0x81bb2d30 [0m) + 0x2d0 8 81bb2cf4 (+ 224) 800988e4 <kernel_x86> evaluate_debug_command + 0x80 9 81bb2dd4 (+ 64) 80092a3e <kernel_x86> kernel_debugger_loop( [34m0x801700f7 [0m [36m"PANIC: " [0m, [34m0x80152064 [0m [36m"port %ld: no messages found " [0m, [34m0x81bb2e80 [0m [36m"� " [0m, int32: [34m3 [0m) + 0x32a 10 81bb2e14 (+ 48) 80092c93 <kernel_x86> kernel_debugger_internal( [34m0x801700f7 [0m [36m"PANIC: " [0m, [34m0x80152064 [0m [36m"port %ld: no messages found " [0m, [34m0x81bb2e80 [0m [36m"� " [0m, int32: [34m3 [0m) + 0x53 11 81bb2e44 (+ 48) 8009453e <kernel_x86> panic + 0x36 12 81bb2e74 (+ 80) 800634d4 <kernel_x86> _get_port_message_info_etc + 0x2ac 13 81bb2ec4 (+ 80) 80063219 <kernel_x86> port_buffer_size_etc + 0x25 14 81bb2f14 (+ 48) 800643c9 <kernel_x86> _user_port_buffer_size_etc + 0x8d 15 81bb2f44 (+ 100) 80126bd0 <kernel_x86> handle_syscall + 0xcd user iframe at 0x81bb2fa8 (end = 0x81bb3000) eax 0xd4 ebx 0x98c8e8 ecx 0x706bbe30 edx 0xffff0114 esi 0xffffffff edi 0x7fffffff ebp 0x706bbe5c esp 0x81bb2fdc eip 0xffff0114 eflags 0x3216 user esp 0x706bbe30 vector: 0x63, error code: 0x0 16 81bb2fa8 (+ 0) ffff0114 <commpage> commpage_syscall + 0x04 17 706bbe5c (+ 48) 00491b45 <libbe.so> BPrivate::LinkReceiver< [32m0x186d5a38 [0m>::AdjustReplyBuffer(int64: [34m9223372036854775807 [0m) + 0x45 18 706bbe8c (+ 64) 00491c07 <libbe.so> BPrivate::LinkReceiver< [32m0x186d5a38 [0m>::ReadFromPort(int64: [34m9223372036854775807 [0m) + 0x3b 19 706bbecc (+ 48) 004919eb <libbe.so> BPrivate::LinkReceiver< [32m0x186d5a38 [0m>::GetNextMessage( [34m0x706bbf44 [0m, int64: [34m9223372036854775807 [0m) + 0x47 20 706bbefc (+ 128) 002a2c70 <_APP_> ServerWindow< [32m0x186d36d8 [0m>::_MessageLooper( [34m0x0 [0m) + 0x2fc 21 706bbf7c (+ 48) 0027f668 <_APP_> MessageLooper< [32m0x186d36d8 [0m>::_message_thread(NULL) + 0x28 22 706bbfac (+ 48) 008e7893 <libroot.so> _get_next_team_info (nearest) + 0x5f 23 706bbfdc (+ 0) 706bbfec 4713:w:124:TrackerWindow_199_stack@0x70678000 + 0x43fec
Fixed in hrev45274
Fixed in hrev45273
The descritpions and the page that is linked to from the source activity area of the website needs to refer to the hrev that is being reported. We use hrev to identify the build of haiku, hrev is used to identify nightly builds. the hrev will tell us testers if this change should be included in this nightly build.
example: the Source Activity says:
"Lock about window before deleting it on destruction"
and links to: https://github.com/haiku/haiku/commit/19ec4667bc7ca7b40bba7ac54499df4a50c33405
it would be better to have the Source activity say:
"hrev45271 Lock about window before deleting it on destruction"
and link to:
This one is my fault, should be fixed in hrev45271.
This is gcc4 build of hrev45257 on real Hardware.
If you shutdown Haiku with PowerStatus added to the DeskBar,
you will get the attached SegFault in the destructor.
I've tried two different USB thumb drives, a 2GB Verbatim "Store n go" and a 32GB Sandisk Cruzer Glide.
Both USB sticks work just fine with different formatting. I've booted the machine with both in before and after they were Haiku formatted and they worked fine.
I formatted the 2GB both as a YUMI multiboot (before the Haiku boot problems), and as a win98 boot disk to update the BIOS (after the boot problems). Booted fine as both.
But either stick, as soon as I write the Haiku anyboot to it, precisely as per https://www.haiku-os.org/guides/installing/making_haiku_usb_stick which has worked for me any other time, the BIOS locks up as soon as it shows the CPU type.
I have added an "Always on top" menu to th ActivityMonitor's Settings menu. This can be useful if the user want to monitor the performance while working on Haiku.
Patch file has been attached. Tested: working.
Fixed in hrev45266.
Fixed in hrev45266.
With hrev45265 all Trash options were removed from the Tracker prefs.
Just installed Haiku R1A4 on an Acer AX1300 AMD Phenom 2.3GHz Quad Computer. This system has NVidia Sound Chip that R1A4 could not use for some reason so I installed OpenSound and I then saw the NVidia HD Audio in my Media Prefences. Sound was working fine. Reboot system and audio worked fine. Rebooted again, no audio.
I go into Media Preferences and no longer see NVidia HD Audio for Input and output in audio settings.
Multiple Restart Media Services and then reboots of system and it comes back but it seems 50/50 shot between reboots on when audio will work again.
I would say it takes 4 to 5 Restart Media Services