<meleager>
Perhaps if not in the build step, we could help the user with a script to do this at runtime.
<nephele>
I'm not sure i understand the question
<nephele>
why would a user deal with microcode?
HaikuUser has joined #haiku
HaikuUser has quit []
whitepaperkat has joined #haiku
Aedil has quit [Quit: leaving]
nephele has quit [Quit: Vision[]: i've been blurred!]
<meleager>
For secure and correct operation, intel or amd processors should be running latest version of processor firmware. This is done automatically on Linux by initramfs tools.
<meleager>
haiku kernel (arch_cpu.cpp) attempts to load the file from /system/non-packaged/data/firmware, but i didn't see anything that populates the file
OscarL has joined #haiku
<OscarL>
Meleager: you should be able to just "pkgman install intel_microcode". it has a post-install-script that will unpack the correct file for your CPU.
<OscarL>
microcode update for AMD cpus (package: "amd_microcode") is not currently functional (not at least for the CPUs I have).
<meleager>
cool, thanks, will try it out
<OscarL>
Meleager: regarding your earlier question about shorter modify/compile/test cycles... instead of creating a full image, you can just create the haiku.hpkg (and posibly haiku_devel.hpkg) packages, and just install those to test your driver modifications.
<OscarL>
some drivers have no problem being loaded from "non-packaged" location, but as you intend to work on stuff that's needed at boot, using "jam -q -jN @nightly-anyboot haiku.hpkg", and installing the resulting .hpkg sounds advisable.
<meleager>
Thanks, I'll definitely give that a go. I appreciate the specific instructions.
<OscarL>
np. a copy of the original haiku-*.hpkg package will be placed under /system/packages/administrative/state-<timestamp>/ so you can easily revert back to that by using pkgman install <path to that .hpkg>.
<OscarL>
or even boot from that early state from the boot menu, if needed.
OscarL has quit [Quit: "<insert witty quit message here>"]
meleager has quit [Quit: Vision[]: i've been blurred!]
<nekobot>
• OscarL (a9d3265c): python3.14: update to version 3.14.0rc2.
Aedil has joined #haiku
<erysdren>
morning Begasus
<erysdren>
and OscarL too, but he's left already :(
<erysdren>
didnt notice earlier
<Begasus[m]>
Hi there erysdren (@_oftc_erysdren:matrix.org)
<Begasus[m]>
disabled join/leaving in NeoChat, so can't see it here :)
tuaris has quit [Remote host closed the connection]
smalltalkman__ has joined #haiku
jmairboeck has joined #haiku
Aedil has quit [Quit: leaving]
FreeFull has quit [Quit: Lost terminal]
FreeFull has joined #haiku
Begasus_32 has joined #haiku
the_sea_peoples has quit [Ping timeout: 480 seconds]
whitepaperkat has quit [Quit: Konversation terminated!]
Aedil has joined #haiku
<Begasus[m]>
revision bump for labplot later :) (could use Haiku's icon theme) :)
<Begasus[m]>
hmm ... that didn't work ...
<Begasus[m]>
better :P
neoncortex has quit []
n005 has quit [Ping timeout: 480 seconds]
n005 has joined #haiku
mmu_man has joined #haiku
erysdren has quit [Quit: Konversation terminated!]
janking has quit [Quit: Vision[]: i've been blurred!]
_-Caleb-_ has joined #haiku
janking has joined #haiku
jmairboeck has quit [Read error: Connection reset by peer]
FreeFull has quit []
politebot has joined #haiku
stux- has joined #haiku
stux has quit [Ping timeout: 480 seconds]
mmu_man has quit [Ping timeout: 480 seconds]
<Begasus[m]>
another one down :) grabbing calligra-25.08.0-1-x86_64.hpkg and moving it to /Opslag/haikuports/packages/calligra-25.08.0-1-x86_64.hpkg
<Habbie>
hey Begasus[m]
<Habbie>
ever seen hp waiting for build package activation while syslog says it got activated?
<Begasus[m]>
Hi Habbie yeah, it's a known thing
<Begasus[m]>
although it's been a while here, 32bit?
<Habbie>
64 bit
<Habbie>
got any hints for what to do when it happens?
<Begasus[m]>
there is an issue reported at haikuporter
<Habbie>
oh that rings a bell
<Begasus[m]>
if you got one of those that hard headed ... :/
<Begasus[m]>
that "sleep ...." suggestion didn't really did the trick, the comment there from PulkoMandy is the most efficient afaik
<Habbie>
which ticket is it?
<Begasus[m]>
it's at haikuporter (github) not at the bugtracker) :)
<PulkoMandy>
Deleting the entire workdir if you're lazy and don',t need to keep anything from there, but I had partially understood it and you can do a more targetted delete, of the "packages" directory somewhere in the workdir I think
stux- has quit []
stux has joined #haiku
<PulkoMandy>
Make sure to not delete things that are in fact through symlinks to the real /boot/system/packages
<Begasus[m]>
didn't check on 32bit _-Caleb-_ isn't there a version for it?
<Begasus[m]>
still need to tackle a few packages for gear 25.08
<_-Caleb-_>
i've used the last version: calligra_x86 - 3.2.1-10 - x86_gcc2 @ haikuports
<_-Caleb-_>
works fine but im very sure it need an update 😁 libreoffice never works on my pc idk why 😁
<Begasus[m]>
locally got it updated to 25.08.0 on 64bit (with patches from 3dEyes ), iirc starting version 4 there were some issues on 32bit, but it's been a while
<_-Caleb-_>
ah okis, we need a good native word processor :-( (ok i can use gobe iknow)
<Begasus[m]>
we need developers (real ones, not me :D ) to work on those :)
mmu_man is now known as Guest24233
mmu_man has joined #haiku
Guest24233 has quit [Ping timeout: 480 seconds]
nipos has left #haiku [Error from remote client]
nipos has joined #haiku
smalltalkman__ has quit []
<Begasus[m]>
done! :)
<Begasus[m]>
all local packages updated (192) :)
<Begasus[m]>
eeps, it's been busy at the forum in the last days it seems :)
nipos has left #haiku [Error from remote client]
nipos has joined #haiku
<Begasus[m]>
k, done for today, cu peeps!
mmu_man has quit [Ping timeout: 480 seconds]
mmu_man has joined #haiku
Anarchos has joined #haiku
Anarchos has quit [Quit: Vision[]: i've been blurred!]
nukacal has joined #haiku
politebot has quit [Ping timeout: 480 seconds]
dodo75 has joined #haiku
MisthaLu has quit [Remote host closed the connection]
nukacal has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Guest24241 has quit [Read error: Connection reset by peer]
_-Caleb-_ has quit [Quit: Leaving]
melnary has quit [Remote host closed the connection]
melnary has joined #haiku
Aedil has quit [Quit: leaving]
Anarchos has joined #haiku
melnary_ has joined #haiku
melnary has quit [Ping timeout: 480 seconds]
melnary has joined #haiku
melnary_ has quit [Ping timeout: 480 seconds]
DKnoto has quit [Quit: Leaving]
DKnoto has joined #haiku
<Anarchos>
i need advice about mutex and rw_spinlock
<phschafft>
hm?
<Habbie>
Anarchos, just ask your questions
<Anarchos>
i have one function in my driver which writes wvalues in variables, and another who read the variables and put them in a buffer. Should i use a mutex or a rw_spinlock is better in that case ?
<Anarchos>
I see rw_spinlock is used in the kernel, but not in drivers
<Anarchos>
Habbie phschafft still there, buddies ?
<Habbie>
i am
<phschafft>
hm.
<phschafft>
there might be a good number of kernel specific details here that may matter.
<phschafft>
I can only speak generally:
<phschafft>
a rwlock is generally a good idea if you have clear reader and writers. e.g. inserting into a buffer and reading from that buffer. note that if you got a rwlock's read lock, then you MUST NOT write. this includes things like flags (e.g. buffer fullness).
<phschafft>
a mutex is fine if you have a lot of mixed access (read and write) within the same locking.
<phschafft>
the rwlock is generally more performanent if you have many readers, as they don't need to wait for each other (any number of read locks can be given out at the same time, just no mix between read and write locks). a mutex however pins you down to always one lock (== thread).
<Habbie>
yep
<phschafft>
spinlocks are used to keep the CPU hammering the lock. so if you wait in a spinlock you *will* consume all CPU power there is and other threads might not run as expected.
<phschafft>
however they tend to be more performant if you know that you will only wait a few CPU cycles at max.
<phschafft>
a non-spinlock will most likely pass thru the kernel's scheduler at least once.
neoncortex has joined #haiku
<phschafft>
spinlocks are useful e.g. if your peer is some hardware and you just wait for it to finish some lowlevel hardware task.
<phschafft>
I would generally avoid them. specifically if unsure. or if working high level. or if I might wait more than single digit nanoseconds.
<phschafft>
BUT specifically in kernel land there might be other things to consider. such as what the kernel offers, what parts you are taking to, how the kernel is organised, ... and those are are the questions I can't help you with.
<phschafft>
Habbie: feel free to object me. :)
<Habbie>
no objections. considerations are present. go on :)
<Anarchos>
at first i thought to use a mutex, but rw_spinlock seem more appropriate, i am just fear of the 'consume cpu cycles' aspect of spinlocks
<Anarchos>
it is for an accelerometer driver. The acpi handler will writes the accel values in x,y,z, and the read call on the dev file is to get the x,y;z values
<Anarchos>
as x, y and z are three variables, i want to get 'atomic' write/read to them
* phschafft
nods.
<Anarchos>
so i know that both mutex and rw_spinlock can fit, but i do'nt know which is best
<phschafft>
how long do you need to wait on avg?
<Anarchos>
no idea
<phschafft>
22:36 < phschafft> I would generally avoid them. specifically if unsure. or if working high level. or if I might wait more than single digit nanoseconds.
<phschafft>
in that case I would go with the default, a mutex, and then maybe put it into a review as part of merging.
<Anarchos>
phschafft makes sense
<Anarchos>
phschafft the driver is already working , i am just polishing it
Anarchos has quit [Quit: Vision[]: i've been blurred!]