Latest Bugs & Tasks
I've been using an HREV47259 VM inside VMware on a Windows 7 (64-bit) laptop as my main e-mail machine (via BEAM) since late May of 2014. Starting March 6, 2015 sending mail refused to work with the message "535 5.7.8 Error: authentication failed:". POP still works fine with the same user/password combination. (Plain password, unencrypted)
This reminded me that I had installed HREV48786 inside VirtualBox on a different computer in mid-January, and it had this same problem right from the start. In this case it was a 32-bit version of Windows Vista acting as the host. (I filed it under "figure this out when I find time," and it never made it back up to the top of my To Do list.)
In my trouble shooting, I did a fresh install of HREV48871 on two more machines inside VirtualBox: one a Win7-64 machine, the other a Manjaro Linux host. They both refuse to send mail in their Haiku VMs with the same error. SMTP works on both these machines both in the host OSes and in Linux-based virtual machines.
I've played around with all the settings that might have anything to do with networking, with no success. I'm stumped.
Between the last successful e-mail send and when SMTP gave up, I don't think I made any changes in to the host OS or VMware on the machine that used to work but stopped. I believe I did change the account password in that time period, but the old password was the one that refused to work in the first place on the Vista machine, so that seems unlikely to be the culprit. Even if it was, say, the special characters in the password, I tested it out with a dictionary word + a single number password...no dice. Also, I'd tried sending on both port 25 and 587, so that's not it. And it doesn't seem like it's a problem with the mail server or mail account in question, because I tried it out with more than one account and mail server. Plus, why would it work for POP, but not SMTP? Sigh.
I took one stab at trying to use Mail to send, but it died silently--as Mail is wont to do--and I don't think I ever got it to work even last year when BEAM worked without porblems, so I don't know if this is specific to the application.
recently, I encountered the following problem:
Backed up an installation directory for a Haiku app to a NTFS partition. When copying the files back to a newly created BeFS partition, the binary file of the app cannot be started any more (The file cannot be opened with Tracker("Invalid argument")).
Expected behavior: The restored app should start without any errors.
Apparently, some meta-information gets lost if a binary file is copied to a NTFS partition.
for my network connection here, I have to configure a proxy for HTTP and HTTPS.
Unfortunately, only HTTP pages load properly, HTTPS pages do not. WebPositive is then stuck at "Request sent..." and nothing else happens.
Haiku has made it into the news on German Heise Newsticker.
Having already read about the OS and its history before, I decided to give it a try. Downloaded the latest Anyboot image and wrote it on an empty USB stick.
The stick first failed to boot ("could not find a bootable partition") but that could be fixed by attaching the USB stick directly to the PC and not via USB hub.
But the second attempt to boot Haiku was not successful either.
unhandled page fault in kernel space at 0x0, ip0x816592f3
I have no clue how to remedy this. The PC is a Dell Latitude E7440 laptop with an Intel Core i7-4600 and 8 GB RAM (which should be fairly enough in my opinion for a modern OS).
Seems that this was it for Haiku here, what a pity. I was indeed curious.
I am using VAIO VGN-FW11E. In hrev48899 after connecting the external display on vga port the laptop display hangs and turn white gradually. Find the attached picture. After disconnecting the external display the main display was displaying normally before. Now the main display is hanging and turning white even after disconnecting the external display. I can use only the external displays now. Before connecting the external display the main display was alright.
The 301-redirect from haiku-os.org to www.haiku-os.org is now in place.
This is important because search engines consider URLs with and without "www" as two different websites, therefore giving the main Haiku website a much lower search ranking than it would otherwise have.
Google provides a help page on how to fix this issue: https://support.google.com/webmasters/answer/93633
To reproduce turn on the pc and don't touch it for more than half an hour.
photos of KDL included.
This is hrev48848.
When I invoke the Backgrounds add-on on some folder, I can't pick a background colour. The "Image" pop-up menu only offers "Default" (which seems to be white) or setting some image. There's no "None" option as there is when dealing with the Desktop/Workspace, which activates the colour picker there.
If you change the screen resolution, the Desktop does not get resized. Best visible with a fullscreen background image.
Booted to desktop then KDL
Steps to reproduce:
- Download the hrev48882 VMware disk image and run it in VMware Workstation 10.
- Compile Haiku from the sources (the usual way, hybrid build).
- Build the es1370 driver (jam -q es1370).
- Double click on the es1370 object file (generated.x86gcc2/objects/haiku/x86_gcc2/release/add-ons/kernel/drivers/audio/ac97/es1370/es1370).
This results in the following output in the serial port (luckily I had logging on):
runtime_loader: /Haiku-git/haiku/generated.x86gcc2/objects/haiku/x86_gcc2/release/system/kernel/kernel.so: Could not find .comment section runtime_loader: /Haiku-git/haiku/generated.x86gcc2/objects/haiku/x86_gcc2/release/system/kernel/kernel.so: Failed to get gcc version. PANIC: page fault, but interrupts were disabled. Touching address 0x00000000 from ip 0x023dd49e Welcome to Kernel Debugging Land... Thread 56488 "es1370" running on CPU 6 stack trace for thread 56488 "es1370" kernel stack: 0x81224000 to 0x81228000 user stack: 0x71835000 to 0x72835000 frame caller <image>:function + offset 0 81227e50 (+ 32) 80142d4e <kernel_x86> arch_debug_stack_trace + 0x12 1 81227e70 (+ 16) 800a32d7 <kernel_x86> stack_trace_trampoline(NULL) + 0x0b 2 81227e80 (+ 12) 80134de6 <kernel_x86> arch_debug_call_with_fault_handler + 0x1b 3 81227e8c (+ 48) 800a4da7 <kernel_x86> debug_call_with_fault_handler + 0x5f 4 81227ebc (+ 64) 800a34eb <kernel_x86> kernel_debugger_loop(^[[34m0x801868b7^[[0m ^[[36m"PANIC: "^[[0m, ^[[34m0x801abbe0^[[0m ^[[36m"page fault, but interrupts were disabled. Touching address %p from ip %p "^[[0m, ^[[34m0x81227f68^[[0m ^[[36m""^[[0m, int32: ^[[34m6^[[0m) + 0x20f 5 81227efc (+ 48) 800a388f <kernel_x86> kernel_debugger_internal(^[[34m0x801868b7^[[0m ^[[36m"PANIC: "^[[0m, ^[[34m0x801abbe0^[[0m ^[[36m"page fault, but interrupts were disabled. Touching address %p from ip %p "^[[0m, ^[[34m0x81227f68^[[0m ^[[36m""^[[0m, int32: ^[[34m6^[[0m) + 0x77 6 81227f2c (+ 48) 800a511a <kernel_x86> panic + 0x3a 7 81227f5c (+ 64) 801444b9 <kernel_x86> x86_page_fault_exception + 0x121 8 81227f9c (+ 12) 8013774e <kernel_x86> int_bottom_user + 0x73 user iframe at 0x81227fa8 (end = 0x81228000) eax 0x1 ebx 0x3202 ecx 0x0 edx 0x24f7220 esi 0x72834ce4 edi 0x24f7220 ebp 0x72834cd8 esp 0x81227fdc eip 0x23dd49e eflags 0x13002 user esp 0x72834cc0 vector: 0xe, error code: 0x4 9 81227fa8 (+ 0) 023dd49e <kernel.so> panic + 0x0e 10 72834cd8 (+ 32) 02449a73 <kernel.so> abort + 0x13 11 72834cf8 (+ 32) 0249473a <kernel.so> __deregister_frame_info + 0xae 12 72834d18 (+ 48) 0129d3fa <es1370@0x0129c000> <unknown> + 0x13fa 13 72834d48 (+ 64) 02654acc </boot/system/runtime_loader@0x02645000> <unknown> + 0xfacc 14 72834d88 (+ 0) 60397250 <commpage> commpage_thread_exit + 0x00 kdebug>
I actually did step 4 by accident; I was trying to copy the driver to /boot/system/non-packaged to see if it works.
vrkosk, unless your issue matches exactly the situation of a closed ticket, please always open a new one. The source of the issue described in this ticket -- runtime_loader crashing when executed like a program -- was explained in comment:2. In your case the runtime loader loads the driver and also the kernel image it was linked against. Apparently the driver and/or its userland kernel execute (initialization) code that confuses the state of the actual kernel (disabling interrupts?). That certainly shouldn't happen. At any rate, it isn't a runtime loader issue.
The following problem only affects Haiku-64bit (tested on hrev48893):
After the latest sqlite update, there is a sqlite package that - even though it is marked as active in HaikuDepot (or is downloaded repeatedly) can't show its contents. The same happens if you try to show its contents in Expander. Additionally, no corresponding sqlite library shows up under /system/libs.
WebPositive is one of the applications affected by missing sqlite.
Applied in hrev48893.
Implemented in hrev48887