Development

The following devices need to be added to src/add-ons/kernel/drivers/common/usb_modeswitch.cpp

Huawei E5377 USB modem/router
Huawei HWD12 LTE USB modem stick

The required code follows:

{ /* MSG_HUAWEI_4 */
0x55, 0x53, 0x42, 0x43, 0x12, 0x34, 0x56, 0x78,
0x00, 0x00, 0x00, 0x00, 0x80, 0x01, 0x0a, 0x11,
0x06, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
},
...
	{{ 0, 0, 0, HUAWEI_VENDOR, 0x1f02}, MSG_HUAWEI_3}, // E5377
	{{ 0, 0, 0, HUAWEI_VENDOR, 0x1f03}, MSG_HUAWEI_4}, // HWD12 LTE

I also note that this file object isn't being created, but I'm fairly unfamiliar with Jam so can't debug it at this stage. Consequently this functionality is missing from the build.

fixed:

Thanks for looking over it. Applied with hrev49142.

* This widget is used in Time and Deskbar. * Partialy fixes #10840. * This widget is used in Time and Deskbar. * Partialy fixes #10840.

* Thanks to Humdinger for point out the problem. * Problem discussed in #10840. * Thanks to Humdinger for point out the problem. * Problem discussed in #10840.

Periodic update BPose's are ones that get updated periodically through TTracker::Pulse() like the volume icons on the desktop with their free space bars. They are kept in a list managed by a global PeriodicUpdatePoses object.

TTracker::Pulse() calls PeriodicUpdatePoses::DoPeriodicUpdate() (Utilities.cpp:222) which locks the PeriodicUpdatePoses object and then locks the looper of each BPoseView where a BPose is to be updated.

When a volume is unmounted the FS notification triggers the BPose representing the volume on the desktop to be removed and destroyed. The BPose destructor then removes itself from the list via PeriodicUpdatePoses::RemovePose() (Utilities.cpp:200). This goes through the list and when it finds the item, it locks the object and removes the BPose. Locking is broken because items are added to the list without locking and the list traversal on remove doesn't happen locked. This should be fixed as well but doesn't affect the deadlock here.

The deadlock happens when DoPeriodicUpdate already holds the lock of PeriodicUpdatePoses but hasn't yet locked the looper of the BPoseView while the FS notification is handled (which means the looper is locked) but hasn't yet caused PeriodicUpdatePoses::RemovePose() to be called.

Attached is a KDL session showing more details. As I am tracking other issues currently and am unsure how this could be fixed cleanly, I'll leave this here without intention of fixing it myself.

A comment in the current virtual memory code states that differently from BeOS, in Haiku it's not possible to delete an area_id created by another team, this should be cleared out in the Haiku Book.

duplicate:

Dupe of #10924

The POSIX API provided by Haiku is missing the declaration and implementation of pthread_condattr_setclock (and maybe pthread_condattr_getclock), so even though Haiku provides a monotonic clock, it is not possible to inform the pthread implementation, that it shall be used.

On 2015-04-14 00:15, Adrien Destugues wrote: On Mon, Apr 13, 2015 at 08:42:04PM -0400, Andrew Hudson wrote: I also think we should now revisit whether the next release is Alpha or Beta. It's been quite a long time since our last serious release discussion, and since that time it is not clear to me that we have made any substantial progress towards resolving the package management issues. ...

On Mon, Apr 13, 2015 at 08:42:04PM -0400, Andrew Hudson wrote: It's been quite a long time since our last serious release discussion, and since that time it is not clear to me that we have made any substantial progress towards resolving the package management issues. If we are stalled on package management, I think that will keep pushing a Beta release out, right?. So the next best option is Alpha 5 release. ...

From: Earl Pottinger dmarc-noreply@xxxxxxxxxxxxx Subject: [haiku-development] Re: The next release noticed that when Haiku is mentioned on websites like OSNews and SlashDot.org that someone always claims the software has not been updated in years because the main Haiku-OS website points to Alpha-4 but there is no easy way for ...

Crashing when accessing a website. Report attached:

One very good reason to do a release whether it be Alpha or Beta is I have noticed that when Haiku is mentioned on websites like OSNews and SlashDot.org that someone always claims the software has not been updated in years because the main Haiku-OS website points to Alpha-4 but there is no easy way for beginners to see that the nightly updates from the same main page. Or at-least add a link to the nightly page on the main page below installing Haiku. ...

Here is a list of requirements: 1) We need the thing to work and schedule build of packages on buildbots, Here is a list of nice-to-have things: ...

13 avril 2015 16:40 Richie Nyhus-Smith richienyhus@xxxxxxxxx a écrit: case, I assign copyright for everything else. If I worked on Haiku sources under contrqct from someone else, they would get the copyright. I don't have stats on that but I think it is the same for most other devs. My point was that right now Haikungfu is as much part of the project as fRiSS ...

On 2015-04-13 09:40, Richie Nyhus-Smith wrote: Not all of the code in Haiku itself has copyright owned by Haiku, inc. In my case, I assign copyright to Haiku, Inc. for code I wrote under contract, but keep the copyright for everything else. If I worked on Haiku sources under contrqct from someone else, they would get the copyright. I don't have stats on that but I think it is the same for most other devs. ...

If I boot 49132 with my Focusrite Scarlett 2i4 attached I either get a garbled display or a KDL. The KDL seems to be caused by Haiku's USB midi support but I don't get a syslog when that happens.

I have attached a syslog dump from booting with the 2i4 attached which resulted in a messed-up display ie no desktop.

On 64 bit platforms a 64 bit size_t was written at the (incorrect) uint32 on the stack, causing the adjacent bytes variable to be clobbered. Because of this, the vectors wouldn't actually be filled with any file data, making the content of files inacessible. On 64 bit platforms a 64 bit size_t was written at the (incorrect) uint32 on the stack, causing the adjacent bytes variable to be clobbered. Because of this, the vectors wouldn't actually be filled with any file data, making the content of files inacessible.