Latest Bugs & Tasks

Syndicate content Haiku
Trac Timeline
Updated: 1 hour 30 min ago

Ticket #11087 (Characters on serial port are buffered with a buffer of size 8.) created

2 hours 56 min ago

I have a small test on a microcontroller. It just sends a single char to the USART every 1.4 seconds.

This works fine in minicom on Linux. On Haiku, both with SerialConnect and Minicom, characters don't get displayed immediately, I have to wait for the microcontroller to send 8 of them before they are processed and read() on the serial port returns.

I tried both a Silicon Labs and a Prolific usb serial converter. Both have the problem. I don't know if the problem is in the TTY layer or the common code in the USB driver.

Categories: Development

Ticket #11086 (when configuring screen saver, screen goes black but cannot return from ...) created

8 hours 27 min ago

On real recent hardware (intel haswell core i3-4330 cpu),
configured the screensaver to lock after 3 minutes.

The screen goes black, but even when moving mouse or typing keyboard, the screen
stay black (crash of screensaver or sleep state (ACPI) not well managed)).

Regards,

Categories: Development

Ticket #11085 (small little os freeze with intel haswell core i3-4330 cpu) created

11 hours 34 min ago

Hi,

On some real hardware (intel haswell core i3-4330 cpu + 2GB memory) and lastest nightly build (hrev47601) I meet some little os freeze for some seconds (1-3 sec) even with low cpu/memory load.
note : the os freeze and run again many time in a single OS session.
I've do not have to reboot the system.

I've not met same behavior on older hardware (intel core 2 duo).

Regards.

Categories: Development

Ticket #11084 (small little os freeze with intel haswell core i3-4330 cpu) created

11 hours 35 min ago

Hi,

On some real hardware (intel haswell core i3-4330 cpu + 2GB memory) and lastest nightly build (hrev47601) I meet some little os freeze for some seconds (1-3 sec) even with low cpu/memory load.
note : the os freeze and run again many time in a single OS session.

I've do not have to reboot the system.

I've not met same behavior on older hardware (intel core 2 duo).

See attachement.

Regards.

Categories: Development

Ticket #11083 (GLTeapot and Haiku3D clipping problem) created

17 hours 1 min ago

Hi,

When launching Haiku3D and GL Teapot, GL Teapot has some clipping problem on the zone shared with Haiku3D.

Found on real hardware (HP 620), with haiku hrev 47601 found on nightly image site.
Also found on virtualbox image with HP pavillon G7.

Regards.

Categories: Development

Ticket #11082 (GLTeapot and Haiku3D clipping problem) created

17 hours 1 min ago

Hi,

When launching Haiku3D and GL Teapot, GL Teapot has some clipping problem on the zone shared with Haiku3D.

Found on real hardware (HP 620), with haiku hrev 47601 found on nightly image site.
Also found on virtualbox image with HP pavillon G7.

Regards.

Categories: Development

Ticket #11081 ([Package Manager] Make system updates robust wrt. format changes) created

Tue, 2014-07-29 18:39

Package or repository format changes can currently easily break the system update support. If a new mandatory feature is introduced -- e.g. support for a new compression algorithm -- an older Haiku won't be able to read packages using that feature. Since the update process requires the packages to be readable to be installed, updating to a Haiku version with packages using that feature isn't possible.

The introduction of those features will happen inevitably, so it would be wise to implement a mechanism that allows updating the system beyond such a feature barrier as soon as possible.

I think a first step should be to extend the repository format to contain either the maximum format version of the contained packages (respectively for each package the format version) or the Haiku version it is backward compatible to. This way the package manager would at least know up front whether using that repository for an upgrade is possible at all.

The next step is to implement some kind of trampoline update mechanism. We first need to activate code that supports the new format. Thereafter we can perform the actual update. Since the package management code isn't some self-contained module/package (yet?) it isn't as simple as updating to a new version of that module.

Categories: Development

Ticket #10882 (Missing search bar on youtube) closed

Tue, 2014-07-29 13:06
fixed
Categories: Development

Ticket #11080 (building haiku on haiku: "GCC version 2.95.3-haiku-2014_07_26 is ...) created

Mon, 2014-07-28 19:42

Using hrev47590 gcc2 hybrid (updated from hrev47579 with pkgman).

When starting to build hrev47590 gcc2 hybrid (jam -q @release-raw) I get the following message:

GCC version 2.95.3-haiku-2014_07_26 is required!
Please download it from www.haiku-os.org...

It seems that gcc2 package in ​http://packages.haiku-os.org/haikuports/master/repo/x86_gcc2/current/packages/ has not been updated so far. The latest entry is for gcc-2.95.3_2013_08_15-4-x86_gcc2.hpkg. The same version is included in the latest available nightly (hrev47581) from ​http://download.haiku-os.org/nightly-images/x86_gcc2_hybrid/.

Categories: Development

Ticket #11078 (Value too large for defined type) closed

Mon, 2014-07-28 15:33
fixed:

Fixed in hrev47586 / a1cce97. Thanks for reporting!

Categories: Development

Ticket #10542 (CSS gradients support not complete) closed

Mon, 2014-07-28 15:23
fixed:

Things are working reasonably well now. Beware of the page linked in this ticket, it is quite old and uses a non-final version of the spec so some gradients won't always render as expected. Please open separate tickets for specific websites if you have more isssues with this.

Categories: Development

Ticket #11079 ("PANIC: _mutex_lock(): double lock" on medium error on audio CD) created

Mon, 2014-07-28 15:22

I just tried using an audio CD from inside VirtualBox, and it currently panics after a lot of check sense errors.

It seems the CD driver ends up calling periph_media_changed_public() which tries to acquire the mutex, when trying to read from the drive from its set_capacity callback called from periph_check_capacity(). The callback is called with the mutex held...

I'm wondering about making the mutex a recursive_lock...

Syslog:

atapi 1-0 error: device indicates transfer error after dma
ata 1 error: device still expects data transfer
check_sense: Medium error
atapi 1-0 error: device indicates transfer error after dma
ata 1 error: device still expects data transfer
check_sense: Medium error
atapi 1-0 error: device indicates transfer error after dma
ata 1 error: device still expects data transfer
check_sense: Medium error
atapi 1-0 error: device indicates transfer error after dma
ata 1 error: device still expects data transfer
check_sense: Medium error
atapi 1-0 error: device indicates transfer error after dma
ata 1 error: device still expects data transfer
check_sense: Medium error
ata 1 error: timeout waiting for interrupt
ata 1 error: RecoverLostInterrupt: lost interrupt, status 0x41
atapi 1-0 error: device indicates transfer error after dma
PANIC: _mutex_lock(): double lock of 0x82b2ff00 by thread 143
Welcome to Kernel Debugging Land...
Thread 143 "media checker" running on CPU 0
stack trace for thread 143 "media checker"
    kernel stack: 0x81a09000 to 0x81a0d000
frame               caller     <image>:function + offset
 0 81a0c448 (+  32) 80142282   <kernel_x86> arch_debug_stack_trace + 0x12
 1 81a0c468 (+  16) 800a219f   <kernel_x86> stack_trace_trampoline(NULL) + 0x0b
 2 81a0c478 (+  12) 80133fbe   <kernel_x86> arch_debug_call_with_fault_handler + 0x1b
 3 81a0c484 (+  48) 800a3d0a   <kernel_x86> debug_call_with_fault_handler + 0x5a
 4 81a0c4b4 (+  64) 800a23bb   <kernel_x86> kernel_debugger_loop(0x80185bd7 "PANIC: ", 0x80180c80 "_mutex_lock(): double lock of %p by thread %ld", 0x81a0c560 "", int32: 0) + 0x217
 5 81a0c4f4 (+  48) 800a2737   <kernel_x86> kernel_debugger_internal(0x80185bd7 "PANIC: ", 0x80180c80 "_mutex_lock(): double lock of %p by thread %ld", 0x81a0c560 "", int32: 0) + 0x53
 6 81a0c524 (+  48) 800a4092   <kernel_x86> panic + 0x3a
 7 81a0c554 (+  64) 80090948   <kernel_x86> _mutex_lock + 0xe8
 8 81a0c594 (+  48) 819e4309   <scsi_periph> periph_media_changed_public(scsi_periph_device_info*: 0x82b2fed8) + 0x25
 9 81a0c5c4 (+ 112) 819e421d   <scsi_periph> periph_media_changed(scsi_periph_device_info*: 0x82b2fed8, scsi_ccb*: 0x8274fd9c) + 0x4d
10 81a0c634 (+  48) 819e2cd5   <scsi_periph> check_sense(scsi_periph_device_info*: 0x81a0c71c, scsi_ccb*: 0x82b2fed8) + 0x1b1
11 81a0c664 (+  48) 819e3236   <scsi_periph> check_scsi_status(scsi_periph_device_info*: 0x81a0c71c, scsi_ccb*: 0x82b2fed8) + 0xfa
12 81a0c694 (+  48) 819e34b6   <scsi_periph> periph_check_error(scsi_periph_device_info*: 0x81a0c71c, scsi_ccb*: 0x82b2fed8) + 0x226
13 81a0c6c4 (+  96) 819e3d4b   <scsi_periph> read_write(scsi_periph_device_info*: 0x82b2fed8, scsi_ccb*: 0x8274fd9c, IOOperation*: NULL, uint64: 0x7ffd3 (524243), uint32: 0x2 (2), physical_entry*: 0x81a0c804, uint32: 0x2 (2), false, 0x81a0c7f4) + 0x327
14 81a0c724 (+  80) 819e40c3   <scsi_periph> periph_read_write(scsi_periph_device_info*: 0x82b2fed8, scsi_ccb*: 0x8274fd9c, uint64: 0x7ffd3 (524243), uint32: 0x2 (2), physical_entry*: 0x81a0c804, uint32: 0x2 (2), false, 0x81a0c7f4) + 0x47
15 81a0c774 (+ 208) 81a2f38c   <scsi_cd> test_capacity(cd_driver_info*: 0x82a64ae0) + 0x194
16 81a0c844 (+  64) 81a308ab   <scsi_cd> cd_set_capacity(cd_driver_info*: 0x82a64ae0, uint64: 0x7ffff (524287), uint32: 0x800 (2048)) + 0x1db
17 81a0c884 (+  80) 819e267f   <scsi_periph> periph_check_capacity(scsi_periph_device_info*: 0x82b2fed8, scsi_ccb*: 0x8274f6d4) + 0x1d3
18 81a0c8d4 (+  48) 81a30951   <scsi_cd> cd_media_changed(cd_driver_info*: 0x82a64ae0, scsi_ccb*: 0x8274f6d4) + 0x49
19 81a0c904 (+ 112) 819e4286   <scsi_periph> periph_media_changed(scsi_periph_device_info*: 0x82b2fed8, scsi_ccb*: 0x8274f6d4) + 0xb6
20 81a0c974 (+  48) 819e2cd5   <scsi_periph> check_sense(scsi_periph_device_info*: 0x81a0ca7c, scsi_ccb*: 0x82b2fed8) + 0x1b1
21 81a0c9a4 (+  48) 819e3236   <scsi_periph> check_scsi_status(scsi_periph_device_info*: 0x81a0ca7c, scsi_ccb*: 0x82b2fed8) + 0xfa
22 81a0c9d4 (+  48) 819e34b6   <scsi_periph> periph_check_error(scsi_periph_device_info*: 0x81a0ca7c, scsi_ccb*: 0x82b2fed8) + 0x226
23 81a0ca04 (+  48) 819e43cb   <scsi_periph> send_tur(scsi_periph_device_info*: 0x81a0ca7c, scsi_ccb*: 0x82b2fed8) + 0x93
24 81a0ca34 (+  80) 819e4410   <scsi_periph> wait_for_ready(scsi_periph_device_info*: 0x81a0cabc, scsi_ccb*: 0x82b2fed8) + 0x34
25 81a0ca84 (+  64) 819e452c   <scsi_periph> periph_get_media_status(scsi_periph_handle_info*: 0x82b41c80) + 0xa0
26 81a0cac4 (+ 320) 819e3ebb   <scsi_periph> periph_ioctl(scsi_periph_handle_info*: 0x82b41c80, int32: 15, 0x82a4a45c, uint32: 0x3282 (12930)) + 0x6f
27 81a0cc04 (+ 112) 81a306c4   <scsi_cd> cd_ioctl(0x80bffdd0, uint32: 0xf (15), 0x82a4a45c, uint32: 0x3282 (12930)) + 0x404
28 81a0cc74 (+  48) 800b45db   <kernel_x86> BPrivate::AbstractModuleDevice<0x82a64b10>::Control(0x80bffdd0, int32: 15, int32: -2103139236, uint32: 0x3282 (12930)) + 0x23
29 81a0cca4 (+ 352) 800b9de5   <kernel_x86> devfs_ioctl(fs_volume*: 0x82a63230, fs_vnode*: 0x82b2fac8, 0x80bffde0, uint32: 0xf (15), 0x82a4a45c, uint32: 0x3282 (12930)) + 0x229
30 81a0ce04 (+  64) 800f09a0   <kernel_x86> common_ioctl(file_descriptor*: 0x82a64e70, uint32: 0xf (15), 0x82a4a45c, uint32: 0x3282 (12930)) + 0x38
31 81a0ce44 (+  48) 800db86f   <kernel_x86> fd_ioctl(true, int32: 6, uint32: 0xf (15), 0x82a4a45c, uint32: 0x3282 (12930)) + 0x5f
32 81a0ce74 (+  80) 800dd154   <kernel_x86> _kern_ioctl + 0x4c
33 81a0cec4 (+  48) 80154068   <kernel_x86> ioctl + 0x1c
34 81a0cef4 (+  64) 800cffcf   <kernel_x86> BPrivate::DiskDevice::KDiskDevice<0x82a4a380>::GetMediaStatus(0x82a4a45c) + 0x23
35 81a0cf34 (+  32) 800cfc73   <kernel_x86> BPrivate::DiskDevice::KDiskDevice<0x82a4a380>::UpdateMediaStatusIfNeeded(0x81a00001) + 0x2b
36 81a0cf54 (+  64) 800d3205   <kernel_x86> BPrivate::DiskDevice::KDiskDeviceManager<0x82819900>::_CheckMediaStatus(0xcccccccc) + 0x8d
37 81a0cf94 (+  32) 800d3396   <kernel_x86> BPrivate::DiskDevice::KDiskDeviceManager<0x82819900>::_CheckMediaStatusDaemon(0xcccccccc) + 0x12
38 81a0cfb4 (+  48) 80081edb   <kernel_x86> common_thread_entry(0x81a0cff0) + 0x3b
kdebug> mutex  0x82b2ff00
mutex 0x82b2ff00:
  name:            SCSI_PERIPH
  flags:           0x0
  holder:          143
  waiting threads:
kdebug> thread
THREAD: 0x829bb840
id:                 143 (0x8f)
serial_number:      143
name:               "media checker"
hash_next:          0x00000000
team_next:          0x829bc0a0
priority:           10 (I/O: -1)
state:              running
cpu:                0x801bf9c0 (0)
sig_pending:        0x0 (blocked: 0x0, before sigsuspend(): 0x0)
in_kernel:          1
fault_handler:      0x00000000
team:               0x8290f600, "kernel_team"
  exit.sem:         565
  exit.status:      0x0 (No error)
  exit.waiters:
kernel_stack_area:  263
kernel_stack_base:  0x81a09000
user_stack_area:    -1
user_stack_base:    0x00000000
user_local_storage: 0x00000000
user_thread:        0x00000000
kernel_errno:       0x0 (No error)
kernel_time:        7435501
user_time:          0
flags:              0x0
architecture dependant section:
	esp: 0x81a0c3c8
	ss: 0x82a60010
	fpu_state at 0x829bba30
scheduler data:
	priority_penalty:	3
	additional_penalty:	6 (24898)
	effective_priority:	1
	time_used:		6 us (quantum: 4700 us)
	stolen_time:		32206 us
	quantum_start:		22040432552 us
	needed_load:		0%
	went_sleep:		22030416374
	went_sleep_active:	4220906585
	core:			0
	cache affinity has expired
Categories: Development

Ticket #9605 (Web+ sometimes fails to download FTP URLs) closed

Mon, 2014-07-28 14:38
fixed:

The current FTP issue is tracked in #9905. When that is done we will have a nice directory listing, as was tested with file: and gopher: protocols already.

Categories: Development

Ticket #10629 (openstreetmap.org doesn't render map tiles) closed

Mon, 2014-07-28 14:26
fixed:

It works great now (also on yandex).

Categories: Development