Latest Bugs & Tasks
Booting haiku x86_64 with ps2 wireless mouse freezes at rocket icon. If I boot with no calls to BIOS, in debug options it will boot and the mouse is useable. Also if I swap the mouse for a usb mouse it will boot without using any boot debug settings.
- Boot haiku with ps2 mouse (might need a specific wireless and brand Logitech Mouseman)
Result: freeze at rocket icon. Sometimes will boot to desktop but then freezes after a few seconds.
Instead in 1 swap the ps2 mouse with usb mouse and there is no freeze.
The outsourced libqrencode library used by the qrencode kernel debugger addon is not built to be usable from the kernel debugger. It was outsourced in hrev47126, which shows the culprit: the Jamfile redefined the malloc functions to use their kernel debugger equivalent when building the libqrencode sources, which the outsourced package doesn't do. Using the addon results in normal kernel heap functions being used, which mustn't be used inside the kernel debugger.
I see three options:
- Put the sources back so the library can be built with the defines again.
- Build a kernel debugger version of the libqrencode package.
- Remove the qrencode kernel debugger addon completely.
Since the addon doesn't seem to be in broad use (probably due to it's non-intuitive interface), removing it would be an easy way out. Building a kernel debugger aware package shouldn't be too involved either, as it's just about redefining the malloc functions.
Removed in hrev48038.
Build is still broken, see line 292 in /haiku/build/jam/packages/Haiku.
There is still /haiku/data/system/data/Canna remaining, along with the (currently build-breaking) references to canna in /haiku/build/jam/packages/Haiku.
Removed in hrev48034.
Tentative fix in hrev48033. Hard to tell if that's the right fix without a way to reproduce the problem.
From dsuden, in circa r 47990, NULL dereference within this path:
0x79ae2530 0xfd41dc BHttpRequest::_MakeRequest() + 0x334 0x79ae2610 0xfd38ef BHttpRequest::_ProtocolLoop() + 0x1d7 0x79ae2650 0xfde4b8 BUrlRequest::_ThreadEntry(void*) + 0x40
Didn't happen again, and never saw that myself, might well be just a freak occurence.
Ticket #11349 ("unhandled page fault in kernel space at 0xdeadbefb" while running python ...) created
This is reproductible by running the python 2.7.8 testsuite.
The crash happens in TCPEndpoint::IsBound called from TCPEndpoint destructor via EndpointManager::Unbind. This occues in the "loop consumer" thread when it calls socket_release.
Sometimes I want to navigate through directories in open/save file panel with keyboard, but it is impossible, since the window intercepts Enter and Space key presses, thinking I wanted to press the default button and close the window.
You can see it in action by compiling:
Fixed in hrev48021.
According to Gutenprint's "Supported Printers" page, all of the printers that we have drivers for (Canon LIPS, PCL5/6) are supported by Gutenprint. Is there any reason to keep these drivers around then?
Francois noted that most of the information provided by makebootable is passed to the kernel by the BIOS. He said that most modern BIOSes did this but we'd have to check for older ones (or maybe ask the GRUB team if they know anything...)
Ticket #11344 (KDL while running PHP testsuite: "failed to acquire spinlock %p for a long ...) created
A recipe for php 5.6.2 is available at haikuports. Building it and running the testsuite results in a repeatable KDL. the error happens in _php_stream_fopen_from_pipe which calls _user_unmap_memory and ens up in a reschedule.
I tried to debug this as requested in #11032, but results are strange. running shows that the 3 other cores in my CPU are running idle threads. This looks correct, the machine freezes for a short time before it panics, but it is unexpected.
Trying to analyze the spinlock results in locked from 0x0000000. So it looks something went wrong with the spinlock.
This is hrev48029.
I've set the formatting in the Locale prefs to German, but checked the box to "use month/day-names from preferred language" (which is English).
With this Tracker shows the "Modified" column like this:
The German "um" should be "at", English like the rest of the date.
We may want to change that option to "Use date/time names from preferred language"?
I guess this is a Tracker issue?