<mjg>
pid 711: rename bbbb -> aaaa/cccc: General system error
<mjg>
pid 711: rename cccc -> aaaa/dddd: General system error
<mjg>
pid 711: rename bbbb -> dddd/aaaa/bbbb: General system error
<mjg>
running the newest snap dated 2021: hrev55181+51
<mjg>
in /var/log/syslog i found:
<mjg>
KERN: vnode 3:786778 is not becoming unbusy!
<mjg>
KERN: vnode 3:786988 is not becoming unbusy!
<mjg>
numerous times
<mjg>
back to profiling, preferably i would be able to get a flamegraph from the kernel
<waddlesplash>
the profile tool can profile the whole system
<waddlesplash>
however it's rarely used in that mode. you can also just have it collect hits from both kernel and userland when profiling individual applications; in fact it does this by default I believe
<waddlesplash>
mjg: that snap is quite old. you should use a nightly build anyway
<mjg>
is there a way to have it collect stacktraces?
<mjg>
something which can be fed into flamegraph.pl
<waddlesplash>
however, these have more debugging and assertions turned on, so that makes things slower
<waddlesplash>
you can have it collect information in Callgrind format, yes
<waddlesplash>
which includes full stack traces
<x512[m]>
My "shmfs" (in memory file system) is some kind of working:
<waddlesplash>
however as I noted these are built with KDEBUG_LEVEL=2
<waddlesplash>
which has performance impacts significant enough they are noticeable in the GUI
<waddlesplash>
however despite that it's still faster than R1/beta3 in some ways due to optimzations made in the last year and a half
<mjg>
look, i don't have any seirous interest in haiku, just booted it for some fun this evening
<mjg>
i reported one bug with dirconc above, someone probably should look into it, most likely also reproduces on freash stuff unless someone specifically targeted it
<mjg>
for the perf "evaluation" i'm doing looks like i would need to recompile by hand without debug, which goes beyond the time i'm willing ot invest
<waddlesplash>
a full system rebuild takes about 2 hours on a circa 2015 dual core machine and way less on something beefier
<waddlesplash>
i.e. a handful of minutes on my Ryzen
<waddlesplash>
if you only want to rebuild the kernel+base system it's even faster, and only requires a checkout as most tools are included in the default install that you need to build with
<mjg>
i'm afraid my laptop is even older :-p
<waddlesplash>
well, it's much easier than rebuilding FreeBSD anyway :)
<mjg>
if you can ship me fresh kernel without debug i would be happy to use it
<waddlesplash>
if you wait a few days there will be such builds since I'm about to kick of the release process
<mjg>
*that* i'm doing in much faster hw
<waddlesplash>
release branches have debugging turned down
<mjg>
ye i can check in few weeks from now
<waddlesplash>
anyway, looking at that function very quickly
<waddlesplash>
I'm not sure why the locks are acquired before the vnode dec
<waddlesplash>
presumably if the count is still > 0 we are just going to return and nothing will happen
<mjg>
i'm guessing the only case where there is a problem is 1->0 transition
<waddlesplash>
the inc_() function indeed just atomic_add's without touching locks
<waddlesplash>
I am going to make a bet that this function has been this way for $long_time perhaps even back to when the kernel was C and not C++ :)
<x512[m]>
NewOS remains?
<waddlesplash>
mjg: anyway if you're looking for easy performance wins there's going to be a ton of them. every few months I stumble across a 10-15% uplift basically without even looking for it.
<waddlesplash>
I fixed a scheduler bug a few months back which was that
<mjg>
waddlesplash: well, let me put it this way
<mjg>
waddlesplash: there is a person $elsewhere with their own os and some interest in multicore performance
<mjg>
waddlesplash: i'm hoping to taunt them with haiku :-P
<mjg>
no the most wholesome motivation but here it is
<waddlesplash>
oh, well, we have some interesting stuff going on that's for sure even before performance is a factor
<waddlesplash>
there a lot of very well designed but underutilized facilities in the kernel for this kind of thing
<waddlesplash>
as you saw above, that function which deals with multiple atomics and 2 locks has no GOTO in it!
<waddlesplash>
I've never checked but I'm pretty sure the Haiku kernel has the absolute least goto per capita out of any OS except maybe the experimental Rust ones
<waddlesplash>
because we foist all that responsibility on the compiler and RAII
<waddlesplash>
originally there was a real reason locks were needed at the beginning before doing work
<waddlesplash>
then it got moved, but locking wasn't elided
<waddlesplash>
not back to the C days, but before the liberal conversion to Lockers, there's still a raw mutex_lock there
dev has quit [Ping timeout: 480 seconds]
<x512[m]>
waddlesplash: vfs.cpp have crazy GOTO code with funny comments.
<waddlesplash>
x512[m]: in a few rare places, yes
<mjg>
well i don't know what the constraints this code is working in, so far it seems it wants the dec-if-not-1 idiom
<waddlesplash>
none constraints
<waddlesplash>
the vfs is not any kind of special. some parts of it may be spinlocked but you can see where those are clearly
<waddlesplash>
mjg: Haiku's kernel was never GIANT locked, ever, so we have no vestiges of that even a little bit
<mjg>
oh?
<mjg>
did it start with smp?
<waddlesplash>
for instance we don't have SX locks. you can sleep within any lock if you want. kind of not encouraged but hey
<waddlesplash>
yep
<mjg>
do i know you? you keep throwing around freebs terminology here
vdamewood has quit [Quit: Life beckons.]
<waddlesplash>
yes, because I maintain the FreeBSD compatibility layer we use for WiFi/ether drivers
<waddlesplash>
and I see you are a BSD person so I figured you would understand it :)
<waddlesplash>
as for whether you know me I don't know. I hang around BSD WiFi and sometimes ethernet people on EFnet. sometimes a patch or two from me gets merged to FreeBSD, usually by kevans91
<mjg>
i mostly meant that perhaps you hang out at #osdev under different nickname or similar
<waddlesplash>
ah. nope
<x512[m]>
Note that BeOS (ancestor of Haiku) was one of first OSes that popularized SMP. It used 2 CPUs PC from first versions.
<mjg>
cool
<waddlesplash>
yes
<waddlesplash>
and the original base of the Haiku kernel was NewOS, which was a research OS project started by an ex-Be employee
<mjg>
that bit i learned few weeks back
<waddlesplash>
which had not a few paradigms pioneered by Be in it, back in the days where even Linux was giant locked
<x512[m]>
SMP is one of Haiku design priorities.
vdamewood has joined #haiku
<waddlesplash>
yes
<mjg>
he happens to hang out on #osdev :P
<waddlesplash>
not sure how much you know about that, but we have threads everywhere and for everything
<waddlesplash>
every window is its own thread
<mjg>
i know next to nothing about beos nor haiku
<waddlesplash>
(and the display server has another thread to handle requests from that window)
<waddlesplash>
so 2 threads for every window in the GUI, one on the client and one on the server
<mjg>
i do note getting to the terminal should be handier though :)
<mjg>
if there is a gui shortcut i failed to find it
<waddlesplash>
right click on any file manager (including desktop) -> option in Addons window
<waddlesplash>
and it has a shortcut too. so any time you have the desktop or a file window in focus, use the shortcut to open a new terminal window
<waddlesplash>
if you prefer Windows/Linux style shortcuts (Ctrl instead of Alt/Cmd for accelerators), there's an option to change things system wide in Keymap preferences
* augiedoggie_
wants system wide emacs shortcuts :P
<waddlesplash>
the snooze() should only be for BUSY_VNODE_DELAY which is 5 milliseconds
<mjg>
is that basically an arbitrary sleep?
<waddlesplash>
no
<waddlesplash>
it only happens if the vnode is currently in BUSY state
<waddlesplash>
and wait=true, otherwise we return EBUSY immediately
<mjg>
right, but should you find it in that state, do you just go off cpu for said arbitrary period?
<waddlesplash>
yes
<mjg>
right, so that should not be happening
<waddlesplash>
it should not happen very often, vnode business is not a common occurence
<x512[m]>
Isn't it possible to use ConditionVariable instead of snooze?
<waddlesplash>
anyway it's 5ms. that can add up but somehow it's adding up 1. to multiple seconds 2. it's stopping other I/O during this period
<mjg>
the kernel should have infra to let threads go off cpu and have wakesup
<waddlesplash>
mjg: it does, we have cvars
<mjg>
well then :)
<waddlesplash>
however, I think right now this is a symptom, fixing this will be good but there's some other problem
<waddlesplash>
we should not be holding whatever locks we are holding to cause all IO to stall during this wait
<waddlesplash>
however long or short it may be
<mjg>
i do note this test runs into contention on vnode locks by design and gang waiting on i/o in some form will have to happen
<x512[m]>
It think it is BFS driver bug that handle journal inefficiently.
<mjg>
without arbtirary sleeps
<waddlesplash>
x512[m]: yeah but we shouldn't stall on reads
<waddlesplash>
trying to do things in the GUI that shouldn't be hitting writes also stalls here
<waddlesplash>
ah, it appears we have an up to 10s wait here. the 5ms is just the increments we do it in. so the real question is, what's holding us up
<mjg>
do you have something to verify lock ordering?
<mjg>
with the crazy renames you may very well be deadlocking, but i don't know what haiku does in that case
<waddlesplash>
like, aside from asserts?
<waddlesplash>
well it can't be a full deadlock
<waddlesplash>
because the system goes back to normal and the program exits cleanly
<waddlesplash>
just takes a bit
<mjg>
maybe you time out some locks and kill offenders
<mjg>
again not famliar with the code
<waddlesplash>
timeout in vfs will return EBUSY
<waddlesplash>
we can't do anything about deadlocks in the kernel, if that happens you're sunk and have to just hard reboot
<waddlesplash>
so yes this could be working by hitting VFS timeouts
<waddlesplash>
in Haiku the expensive stuff is create/delete due to very carefully locked journal
<waddlesplash>
writes to data area of the fs can and are parallel
<mjg>
also unlink, so if you run 2 or more workers you should be back at vnodes being busy
<waddlesplash>
the expensive part appears to be vnode lookup in rename() for this test
<waddlesplash>
that's where we hit most contention
<waddlesplash>
because it's happening inside a transaction lock
<mjg>
on the modified dir
<waddlesplash>
which raises the further question, why is there a busy vnode when this thread owns the transaction lock?
<mjg>
well i did my "duty" by reporting and giving a reproducer, have fun :)
<mjg>
will check in 2-3 weeks
<waddlesplash>
guess there's some way for vnodes to be busy outside transactions. I'm not really familiar with this part of VFS
Maturi0n_ has joined #haiku
<waddlesplash>
so, the vnode we are waiting for is in "removed" state
<waddlesplash>
interesting
Maturi0n has quit [Ping timeout: 480 seconds]
mmu_man has quit [Ping timeout: 480 seconds]
rennj has quit [Ping timeout: 480 seconds]
rennj has joined #haiku
rennj has quit [Ping timeout: 480 seconds]
Maturi0n has joined #haiku
rennj has joined #haiku
Maturi0n_ has quit [Ping timeout: 480 seconds]
<x512[m]>
I also wanted to implement 9p file system with multiple transport backends: VirtIO (it will allow to have shared host/guest folders in TinyEMU for example), Haiku ports and sockets.
<waddlesplash>
a 9p backend would be nice indeed
<waddlesplash>
mjg: I found a fix for the hangs. previous run was at 15 minutes before I killed it, and don't think it got very far. after the fix it finishes in 1m40s
<waddlesplash>
(this is in a VM)
<mjg>
waddlesplash: diff me
<waddlesplash>
there's still "pid 1920: rename cccc -> bbbb/aaaa/dddd: General system error"
<waddlesplash>
that might be related to the hangs or it might not be, I'm not really sure
<waddlesplash>
if it was EBUSY then it would be almost for sure
<waddlesplash>
but "General system error" is just -1, so, it's possible some other error is getting mistaken for this
<x512[m]>
How VirtIO 9p device should be exposed? It is not a block device but it should allow to mount 9p file system on top op it.
<waddlesplash>
it's a disk, isn't it?
<waddlesplash>
that it doesn't support block read/write doesn't matter
<waddlesplash>
there's other devices in /dev that don't either, like soundcards
<mjg>
waddlesplash: so what's the diff man
<x512[m]>
Are /dev/disk supposed to have only block devices?
<mjg>
waddlesplash: profesionnal curiosity :)
<waddlesplash>
mjg: working on it, going to post it for review
<mjg>
waddlesplash: show me the hack, i promise not to tell
<waddlesplash>
I am typing up the commit message right now lol
<waddlesplash>
mjg: I think I need to check flags only while locked so that probably isn't the exactly correct solution. but it works
<mjg>
hm i think this code is very suspicious to begin with
<mjg>
liveness of the vnode is protected by sVnodeLock?
<waddlesplash>
no?
<waddlesplash>
that lock protects creation/deletion of vnodes
<waddlesplash>
note vnodes themselves each have a lock
<mjg>
after lookup_vnode returns what makes it safe to even lock the vnode
<waddlesplash>
1) holding at least a read lock of sVnodeLock 2) having a reference to the vnode
<mjg>
the current code in the isBusy case makees sure to not access it after locks are dropped
<mjg>
if (!retry_busy_vnode(tries, mountID, vnodeID))
<waddlesplash>
yep
<waddlesplash>
hence my comment above noting we need to access the flag before dropping locks
<mjg>
uh and that's where snooze comes in
<waddlesplash>
yes
<waddlesplash>
so, not easy to do anything but snooze here
<waddlesplash>
haiku doesn't have "wait channels", we have cvar objects, and in this path there are no cvar objects for us to actually use
<mjg>
so in acquire_vnode
<waddlesplash>
well, we could make a global "some vnode became unbusy" one but that may not really be that relevant
<mjg>
is this code even correct?
<mjg>
rw_lock_read_lock(&sVnodeLock);
<mjg>
vnode = lookup_vnode(volume->id, vnodeID);
<mjg>
rw_lock_read_unlock(&sVnodeLock);
<waddlesplash>
what do you mean?
<waddlesplash>
yes
<mjg>
inc_vnode_ref_count(vnode);
<mjg>
what makes this bit legal
<waddlesplash>
what other locks are being held here
<mjg>
i don't see squat
<mjg>
it seems like inc_vnode_ref_count should be performed with &sVnodeLock held
<waddlesplash>
indeed that looks very suspicious
<waddlesplash>
let's check blame
<waddlesplash>
mjg: looks like all consumers of that method are so deep inside vfs code that refcount is always going to be >1 here
<waddlesplash>
well, mostly filesystem drivers not vfs directly
<waddlesplash>
still, that isn't sound, or at least I agree I don't see a way for it to be
<waddlesplash>
that method was added in 2008, possible there was other locking demanded at the time which no longer is
<mjg>
well if the vnode is guaranteed to be there, why even the lookup
<mjg>
and why can it fail
<waddlesplash>
it can fail because lookups can always fail
<waddlesplash>
if you pass in some random number instead of a real ino_t there won't be a vnode
<mjg>
but then this means the vnode is not there?
<mjg>
well let me rephrase. if this code can legitimatley fail, how do you know the non-failing case guarantees this is already a reference
<waddlesplash>
this method is usually used to "pin" vnodes, i.e. to make sure there's no way they'll be evicted while you do some long running operation
<mjg>
which you can safely rely on
<waddlesplash>
so either, the vnode exists and you are going to do the operation, or the vnode doesn't exist in which case you are going to bail out anyway
<waddlesplash>
but yes, this should be fixed
<waddlesplash>
appears this was added pre-Lockers, so writing it the "incorrect" way would have "looked cleaner" but indeed doesn't handle refcounts correctly
<mjg>
i would argue that lookup_vnode returning with an unsecured vnode is a design error
<waddlesplash>
it is secured, you have to call lookup_vnode with at least a read lock
<waddlesplash>
it's only unsecured when you drop the read lock of the table
<waddlesplash>
so, really lookup_vnode needs an ASSERT here clearly indicating that
<mjg>
i mean lookup_vnode does not do anything to make it safe to use without the lock
<mjg>
which goes against the usual pattern
<waddlesplash>
well there are things which don't take a reference
<waddlesplash>
like this very function with the bug, get_vnode, it checks business and if so drops the lock, waits, and tries again
<waddlesplash>
also inc_ref_count can be expensive when going from count 0 to count 1
<mjg>
this is an example of the problem though
<waddlesplash>
note that things with count 0 aren't deleted immediately, on purpose
<mjg>
instead of snooze() for some time it should be able to wait for the object
<mjg>
to find out whatever fate it has
<mjg>
but it also means it has to survive
<waddlesplash>
they're in an "unused" state, they can get evicted when more space is needed
<waddlesplash>
or they can get picked up again and go from 0 -> 1 where some bookkeeping has to occur
<mjg>
.. which means liveness has to be secured in some manner
<waddlesplash>
well, this is a very rare case here. this problem with the "deadlock" does not occur under normal circumstances with regular old 1->0 or 0->1 transition
<mjg>
ok, i'm getting off your back
<waddlesplash>
it only occurs when you have something in Removed+Busy state, which means, "this file was deleted and we are trying to totally evict it"
<mjg>
not my system :>
<waddlesplash>
mjg: I mean, I am not very familiar with the VFS to be honest
<waddlesplash>
I've fixed some critical bugs in it, but otherwise it's not really my domain
<x512[m]>
No matter how rare it is.
<waddlesplash>
it sounds like you know more about VFSes than I do
<mjg>
i happen to be doing vfs elsewhere(tm)
<waddlesplash>
yes, I saw you have committed to FreeBSD's
<mjg>
the problem with arbitrary sleeps is that in principle nothing guarantees that whoever is supposed to do the work you are waiting for
<mjg>
will get to do it
<waddlesplash>
BUSY is a flag that gets used very sparingly
<waddlesplash>
it is not supposed to be set for long periods of time, only when some critical edits are being made to the vnode
<waddlesplash>
it doesn't get set for normal io traffic or something
<waddlesplash>
so when you wind up waiting on it longer than a few ms, that means you are likely in deadlock
<waddlesplash>
which is indeed what the case was here
<waddlesplash>
it's kind of interesting that a rename can deadlock with the removal for precisely this reason. that to me sounds like we should adjust locking order somehow to try and prevent that in the first place.
<mjg>
the solution(tm) is to add a per-mount point rename lock
<mjg>
to effectively bypass the problem
<mjg>
then you unly worry about rmdir, mkdir etc, but all of these are feasible to check for
<mjg>
you don't worry about renames trying to screw you over
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<waddlesplash>
hmm. actually the kdl dumps showed me that the deadlocking vnodes where removed,busy but NOT unpublished
<x512[m]>
My shmfs currently do volume lock on almost everything.
<waddlesplash>
yeah that generally makes sense for ramfs
<waddlesplash>
there's other filesystems that have to do that too, like ntfs
<waddlesplash>
aggressive caching helps a lot
<mjg>
i think it partially defeats the point of a tmpfs
<mjg>
things like to get contested if you use it in a multicore setup
<x512[m]>
Lets make it not cause kernel panics first.
<mjg>
decent plan
<mjg>
:)
<x512[m]>
It is a few days work of person who never made file system drivers.
HaikuUser has joined #haiku
<x512[m]>
Tested on RISC-V virtual machine.
<waddlesplash>
we really need to get riscv package builders
<waddlesplash>
so people can start trying to use riscv haiku for real
<x512[m]>
Only x86[_64] and riscv64 are actually functional.
<x512[m]>
arm[64] are near to be functional.
<mjg>
FUNCTION(_arch_cpu_user_memcpy): // TODO retl nop
<mjg>
FUNCTION_END(_arch_cpu_user_memcpy)
<mjg>
i see what you mean
<x512[m]>
riscv64 Haiku supports SMP.
<mjg>
is m68k even fast enough to run haiku?
<x512[m]>
On emulator no problem I think.
<waddlesplash>
mjg: probably
<waddlesplash>
you can run Haiku on Athlon XP systems from the early '00s and it's perfectly reasonable speeds
<waddlesplash>
mjg: sparc stuff was mostly for funsies, it's nowhere near getting to userland. as you can see ARM has a real impl, and then arm64 uses generic_user_memory impls I think
<mjg>
i'm pretty sure motorla 68k is nowhere near athlon xp :-p
<waddlesplash>
mjg: basically status is: x86,64 fully functional + ports binary builds available. riscv fully functional - no ports binaries, arm,64 get to userland start on qemu before running into problems, ppc used to at least get to mount disk but probably doesn't anymore, m68k got past bootloader and into kernel once or twice, mips was a fun thing I don't know much about, sparc gets to kernel and maybe some paging but not further
<OscarL>
humdinger: my original intention was to automagically put that fix into ~/config/settings/ne/.keys...
<humdinger>
agreed
<OscarL>
I just failed miserably after a fight with GLOBAL_WRITTIBLE_FILES / USER_SETTINGS_FILES, and not understanding what I was doing wrong... or if those were not even the thing I should be trying to use to add that file there.
<humdinger>
I recently had to do the same thing for haiku-format
<OscarL>
Original authors will NOT patch ne, because, apparently... it's the termcap/terminfo databases the ones that are wrong in almost all systems... and NOT their software.
<OscarL>
and they refuse to "do the wrong thing".
<humdinger>
not a "nice editor". :)
<OscarL>
Can't blame them...
<OscarL>
but...
<OscarL>
not very nice, indeed :-D
<OscarL>
Begasus: glad you could figure it out!
rennj has joined #haiku
<OscarL>
humdinger: I'll take a look at that recipe, thanks!
<humdinger>
great!
<OscarL>
BTW.... GLOBAL_WRITTIBLE_FILES / USER_SETTINGS_FILES could REALLY use some documenting.
<humdinger>
agreed. we need someone who understands that stuff to write about it...
<OscarL>
(at least, I.... couldn't find anything that made sense to me :-()
<humdinger>
open an issue at haikuports :)
<OscarL>
humdinger: so... the solution is doing the copy on a post-install script, right?
<OscarL>
(I was trying to avoid that, but... oh well)
<humdinger>
you may want to check if there's already a .key file containing those backspace/del entries.In case someone has customized theirs and "ne" gets updated. So you don't just overwrite it.
<Begasus>
But I must say I'm no expert there either :)
<OscarL>
Begasus: yup... but it doesn't explain WHY or in which cases you might want to use them.
<OscarL>
humdinger: agreed. Welp... at least we have a workaround for that darn backspace issue... and a workaround for the recipe to actually use it ... I'll get to it ASAP.
<Begasus>
for global_writable_files I've found that if it's missing haikuporter will cause an warning/error at the end of packaging
<OscarL>
I thought it might help me solve the issue of placing a file into $HOME/config/setting/ or something... and the rest of the docs being rather spartan about those.... I'm easily confused :-D
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
<OscarL>
humdinger: regarding ne... were you too longing for an CLI/TUI editor that doesn't force you to use emacs or vim shorcuts? :-D
<Begasus>
doesn't the source create something like .configfile in HOME?
<OscarL>
Begasus: I've patched it so instead of "~/.ne", it now uses "~/config/settings/ne".
<OscarL>
(I hate .blabla stuff on my $HOME)
<Begasus>
yeah
<Begasus>
should be ok then?
<OscarL>
What I couln't figure out was how to put a file there from the recipe (without resorting to a post-install script)
<OscarL>
*couldn't
<Begasus>
it doesn't install the file (or create it at first launch)?
<OscarL>
The file in question is not part of the original sources, just a workaround I need to use for a very annoying bug that won't ever get fixed upstreamed.
<OscarL>
*upstream.
<Begasus>
ah, then a post-install would be the way to go as humdinger mentioned I guess :)
<OscarL>
As the workaround involves simply modifying some keybindings... I figure that was the best way to include the fix.
<OscarL>
Begasus: alright then! :-D
<OscarL>
as I'm still so new to all of this...
<Begasus>
fighting with lilypond atm here :)
<OscarL>
I'm still trying to learn where the limits are, and how to workaround them... while trying to not get too frustrated, and actually contributing something :-D
<OscarL>
that's Tex related stuff?
<humdinger>
OscarL: yep a nice editor in Terminal that shares most common used shortcuts with our GUI editors was sorely needed IMO.
<Begasus>
yep OscarL
<Begasus>
well it makes use of it :)
<humdinger>
too bad I can't install "ne" on my LibreElec running raspberry...
* OscarL
hugs the lean and mean Lout Typesetting system, while giving the look of dissaproval to the *FAT* Tex :-P
<humdinger>
I wonder if the Haiku project would consider "ne" as a nano replacement.
<OscarL>
humdinger: man... I wish OSMC had an x86 image :-)
<OscarL>
Seems more easy to acces "the linux side" than from LibreELEC.
<Begasus>
granted texlive is a monster, but there is a public for it :)
<humdinger>
yep. LibreElec is all read-only.
<humdinger>
Also latest LibreElec quite unstable for me.
<OscarL>
Begasus: Sure thing! and I commend your work... but do NOT envy it :-D
<humdinger>
or my raspy has issues...
<Begasus>
that one isn't my work OscarL :)
<OscarL>
humdinger: if you have an rpi... tried OSMC yet? (I only know about it what I've read on its website, thou)
<humdinger>
didn't know about OSMC... I need tose streaming add-ons though. have to check what's available there.
<OscarL>
Begasus: saw jmairboeck's work.... but you're still having to test stuff on 32b... I don't even envy having to download Tex :-D
<Begasus>
not that bad, start a build, check the next day if it succeeded :P
<OscarL>
Begasus: LOL.
<Begasus>
ok, missing ghostscript/iapi.h on 32bit
<humdinger>
OSMC seems to be originally a kodi fork. doesn't seem to have the addons I need, at a short glance.
<OscarL>
humdinger: bummer :-(
<humdinger>
I used to run Kodi on RaspberryOS, but they are stuck at kodi v18.7 or something, and people have moved on with their addons. If ever thy update kodi for RasberryOS (or was Raspbian?), I'll go back.
<humdinger>
no stupid read-only stuff there
<OscarL>
OSMC gives you access to "apt", AFAIK.
<OscarL>
so... seems basically a "debian based JEOS" (just enough OS) to run Kodi.
<humdinger>
but not actually running kodi, right?
<OscarL>
that's why I was wishing for an x86 version... can't fully commit to LibreELEC because you have to jump too many hoops to install stuff.
<OscarL>
AFAIK, it does run Kodi... unless they have changed "recently" (since the last time I looked, I mean)
<humdinger>
kodi runs on x86, no?
<humdinger>
looks like I have to keep reading up on OSMC
<OscarL>
humdinger: yeah... I can, and had, installed it on Win and Linux... I just wanted something like LibreELEC (which I also have installed)... but with access to the underlying linux system.
<OscarL>
humdinger: heh, never even thought of using the x86 version of rpiOS :-D
<Begasus>
lol OscarL !
<OscarL>
Everytime I think I got ahead... that darn bastard commits again! :-P
<humdinger>
ah, misread you had a raspberry
<OscarL>
humdinger: well.... all my hardware is so old... that in raw performance... an RPI 400 would actually be an improvement :-D
<humdinger>
Autocommitter is running a marathon, slow but steady with 1/week.
<OscarL>
humdinger: yeah... no way I'll ever beat it in the long rung :-(
<OscarL>
:-D
<Begasus>
OscarL, ghostscript could do with an update :)
<Begasus>
Vulnerabilities for our current version :)
* OscarL
quietly walks backwards whistling.
<Begasus>
hehe
<Begasus>
first tackle lilypond here
<OscarL>
All I wanted was to do some "quick and easy" fix to that darn serial_mouse driver of mine.... Here I am... 3 and a half months later... still adding things to my ToDo list... and I still have not done real progress with the serial mouse :-(
<Begasus>
priorities! ;)
<OscarL>
Anyway... time for a coffee, firing up the VM.. and fix that darn ne recipe! :-P
<Begasus>
but sometimes to fix some thing you need to tackle another one first :)
<OscarL>
Begasus: yeah... I was having way too man papercuts.
<OscarL>
*many
<OscarL>
In fact... I attepted to return to some light Haiku coding a while back... but I was having too many issues... and not being able to separate the real bugs.. from the bugs on my brain... was... too much :-P
<Begasus>
Baby steps, remember? ;)
<netpositive>
yup
<netpositive>
baby steps
<OscarL>
:-)
<netpositive>
and perseverance
<Begasus>
Being around for over 20 years should cover that netpositive ;)
<netpositive>
i'm perfectly aware of that
<OscarL>
Now that Haiku is more stable on my hardware... and I'm... well... doing what I can with myself... it is nice to see even small results after so much head-bashing against the keyboard.
<Begasus>
No wonder you need to patch keystrokes then :P
<netpositive>
Begasus: i'm johnny_b but my nick was taken so i registered this one 8)
<OscarL>
LOL
<Begasus>
Yeah, figured that out a while back netpositive
<netpositive>
touche 8)
<netpositive>
cool
<OscarL>
OscarL <<< BiPolar (not that active online back then but... enough to pester AxelD, JackBurton, and some other fine fellows back then :-P)
<Begasus>
you are mostly the first to respond when I step in netpositive :)
<Begasus>
lol OscarL
jjido has joined #haiku
bitigchi_3 has joined #haiku
rennj has quit [Ping timeout: 480 seconds]
<netpositive>
OscarL: that nick is quite familiar for me
<OscarL>
I was mostly on BeShare from mid 2002 to ends of 2005. Then I moved across the country (Argentina)... and I had no regular internet on my home til recently.
<OscarL>
I always kept watching commit logs, mailing lists, etc, etc, whenever I could... but... only lurking, till recently :-D
<Begasus>
Happy to have you back OscarL !
<netpositive>
the return of BiPolar 8)
<OscarL>
Good thing that my "bipolar" accounts on dev.haiku-os.org and the forums still worked, LOL :-D
<netpositive>
why don't you use it on irc too?
mmu_man has joined #haiku
<OscarL>
netpositive: mmm, dunno... maybe I DO have split personalities... besides being actually bipolar, lol! :-P
<netpositive>
8D
<netpositive>
do you remember Monni the Cat from BeShare?
<OscarL>
Yes, I do.
<OscarL>
and Kancept... AGMS, Andrew Bachmann...
<netpositive>
he was a constant target of jokes being a m$ employee 8p
<OscarL>
I somehow always misremember... who was that wrote the Unizone beshare client for Windows?
<OscarL>
(man... my "English" is still as broken as it was in 2002)
Diver has quit [Ping timeout: 480 seconds]
<netpositive>
i dunno, never used it
<OscarL>
I should dig up my beshare logs from those times, to freshen up my memories of so many memorable people!
<OscarL>
DaaT and his sheeps... mmu_man and his "plop"s...
<OscarL>
Atrus and this catsups :-P
<OscarL>
*his
rennj has joined #haiku
<Begasus>
All familiar :)
<netpositive>
DaaT 8)
<Begasus>
Monni has been my mentor for my English ;)
<Begasus>
DaaT and trout slaps ;)
<netpositive>
DaaT was a big Prodigy fan 8
<netpositive>
8)
<OscarL>
NathanW... bga
<netpositive>
iirc Nathan became a FreeBSD dev
<Begasus>
Monni still has cats :)
<netpositive>
really? 8)
<netpositive>
still at m$?
<Begasus>
Not sure, I only rarely see some pictures from them on FB
<netpositive>
i see
<netpositive>
Zathros and Zaranthos or something...
<Begasus>
cola-coder :)
<netpositive>
ithamar
<Begasus>
yep
<OscarL>
"meow"... LOL I'm having flashbacks :-D
<netpositive>
total recall 8p
jmairboeck has joined #haiku
<Begasus>
hi jmairboeck !
<Begasus>
eeps, just now got a crash when building lilypond jmairboeck (not kidding) :)
<jmairboeck>
hi Begasus! I read that you started to tackle lilypond in the logs
<jmairboeck>
KDL?
<Begasus>
no, crashes
<jmairboeck>
from ghostscript?
<Begasus>
no, from fontforge it seems
<jmairboeck>
how did you fix it?
<jmairboeck>
fontforge I mean
<Begasus>
reverted the first patch found in the repo for fontforge
<OscarL>
(my PC just crashed)... anyway... what I meant was... there's a "repository" folder inside my local clone of haikuports... so using TextSearch inside that... is slower than it should (doe to the amount of things inside that "repository" folder. Would be easier to avoid if it was a "hidden" folder.
<jmairboeck>
OscarL: can TextSearch add custom grep options? for grep there is --exclude-dir
<OscarL>
jmairboeck: AFAIK... no. I was thinking of adding at least reading exclude dirs from a config setting file... (I'm bad at coding in general... terrible at GUI related things without a Delphi-like RAD :-D)
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
<OscarL>
but... I was wanting to avoid all that... if that darn folder could just be renamed :-P
<OscarL>
(I may actually just go ahead and locally patch Haikuporter, LOL)
<Begasus>
hehe
<Begasus_32>
/sources/fontforge-20220308/fontforge/splinefont.h:2637:15: error: conflicting types for 'locale_t'; have 'char *'
<Begasus_32>
2637 | typedef char* locale_t;
<Begasus>
same error on the new fontforge ...
<jmairboeck>
IIRC there were some recent-ish changes regarding locale_t. Are you using beta3 or a nightly?
<x512[m]>
It is needed for POSIX shm_* API to have memory files. Used in Wayland for example.
<andreasdr[m]>
Nice!!!
<x512[m]>
What kind of "RAMDISK" have you tried?
<phschafft>
you use a ramdisk to get into a castle, right?
<andreasdr[m]>
There is a command in Haiku for years to create a ramdisk, after that you can initialize it with drivesetup. I followed a tutorial. I hoped to increase compilation time using it.
<phschafft>
I mean if it's locked.
<andreasdr[m]>
But it was not faster than compiling on SSD
<x512[m]>
This is block device level RAM disk that use the same file system as on disk. shmfs allocates files directly in memory without using block device.
<andreasdr[m]>
Ok.
<andreasdr[m]>
Nice.
<andreasdr[m]>
Any news about kernel events?
<andreasdr[m]>
I saw a commmit with API and empty function bodies aka STUBs
<andreasdr[m]>
:)
<x512[m]>
port read/write callbacks are working, connection with select/async IO notifications are not yet working.
<andreasdr[m]>
Cool. I dont understand this all, but I like the progressssss :)
<x512[m]>
For now select notifications are more important because it can be used for userland FD management in RadeonGfx.
<andreasdr[m]>
Yes. I understood that. Also WINE would benefit.
<andreasdr[m]>
You told
humdinger has quit [Quit: Vision[]: Oi with the poodles already!!]
<x512[m]>
Use pipes for FD based objects (dmabuf, syncobj) and watch pipe read side in RadeonGfx.
<andreasdr[m]>
Nice.
<andreasdr[m]>
Cant wait to seeeee 3d working here. :) But no hurrrrry.
<x512[m]>
I also got an idea how to manage device FDs and introduce add-on system in libdrm2.
<x512[m]>
Currently libdrm2 use stub device ID, it can't handle more than one device and it is hardcoded to RadeonGfx protocol.
<x512[m]>
"libdrm2" is a name of Linux libdrm-compatible implementation that use userland driver instead of kernel.
<andreasdr[m]>
Niiiiiice.
<andreasdr[m]>
Ill totally support that(as far as I can)
<andreasdr[m]>
<3
<x512[m]>
I can't guarantee anything so support in words is enough. It is not contract work or something.
<nekobot>
[haiku/haiku] b4b1561b6a3b - kernel/vfs: Do not wait for removed vnodes to become unbusy.
<nekobot>
[haiku/haiku] 1284e971e2a0 - kernel/vfs: Fix locking behavior in acquire_vnode and add a missing ASSERT.
_Dario_ has quit [Quit: Vision[]: i've been blurred!]
rennj has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
rennj has quit [Ping timeout: 480 seconds]
doppler_ has quit []
mrentropy64 has quit [Quit: Vision[]: i've been blurred!]
doppler has joined #haiku
* augiedoggie_
trout slaps Not-ff83 to wake it up
<augiedoggie_>
still no haikuports notifications :/
<augiedoggie_>
for a while they were coming from a different bot though, botifico iirc
rennj has joined #haiku
<augiedoggie_>
and the 64 bit package builder is stuck on the blender recipe it appears :/
augiedoggie_ is now known as augiedoggie
<waddlesplash>
stuck? I only merged it an hour or two ago
<waddlesplash>
probably just isn't done yet
<augiedoggie>
the log didn't seem to be progressing but maybe i'm impatient
<waddlesplash>
oh, that may be due to some strange behavior I've seen with ninja
<waddlesplash>
since ninja only posts \r and not \n usually and clears the line, sometimes output doesn't actually update until it hits an error and actually posts \n
<augiedoggie>
heh
<waddlesplash>
let's see if I can kick notifico somehow
Not-ff83 was kicked from #haiku by waddlesplash [Not-ff83]
<waddlesplash>
well, the status page at n.tkte.ch indicates that it is receiving the webhooks I am sending
<waddlesplash>
so, why isn't it posting any messages here
botifico has joined #haiku
<botifico>
[haikuports/haikuports] pengphei 68ef973 - capnproto: add new recipe, version 0.10.2 (#7311)
<augiedoggie>
huzzah :P
<waddlesplash>
I switched it to connect without SSL
<waddlesplash>
that's ... not ideal
<augiedoggie>
yeah, weird
<augiedoggie>
iirc, oftc made some changes recently
<rennj>
openboot firmware and opensource hardware/motherboard
<rennj>
802.11s mesh network wifi blob was closed source
<rennj>
7minutes to do was what my 4core/4thread 2015 laptop can do under 30secs
<rennj>
beos vm real 7m48 bc 1.05
<rennj>
beos vm real 2m11 bc 1.06
<rennj>
just changing the bc version
<rennj>
Reinhilde, / =2
DKnoto has quit [Ping timeout: 480 seconds]
<rennj>
i used the olpc xo-1 up in canada big time, the canada border guard stole my asus core2duo/nvidia9300 laptop
<rennj>
heh
<rennj>
400mhz when dual core 2GHz laptop existed
<rennj>
when firefox on 400mhz was still possible
bbjimmy has quit [Quit: Vision[]: i've been blurred!]
<rennj>
my phone is 8x2GHz+ cores, 6GB ram, 256GB storage for $300...the olpc xo-1 give 1 get 1 was like more
<rennj>
i think i payed like $600 or so
DKnoto has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
rennj has quit [Ping timeout: 480 seconds]
bbjimmy has joined #haiku
rennj has joined #haiku
cocobean has joined #haiku
BrunoSpr has quit [Remote host closed the connection]
rennj has quit [Ping timeout: 480 seconds]
jjido has quit [Quit: My laptop has gone to sleep. ZZZzzz…]
vdamewood_ has quit [Read error: Connection reset by peer]
vdamewood has joined #haiku
rennj has joined #haiku
gouchi has joined #haiku
gouchi has quit [Remote host closed the connection]
rennj has quit [Ping timeout: 480 seconds]
Diver has joined #haiku
<waddlesplash>
augiedoggie: that would be surprising to me, basic git operations don't do a lot of deletes, do they?
<waddlesplash>
like, I would be very surprised if "status" is any faster
<augiedoggie>
well, i have git info in my zsh prompt, i have no idea what it's doing in the background to get that data
<waddlesplash>
hmm
<waddlesplash>
well, please do try some basic benchmarks I suppose
<waddlesplash>
I didn't do my usual compilebench because I didn't see why it would be faster
<augiedoggie>
eh, it's probably my imagination
<waddlesplash>
but, it's quite possible it actually is
<waddlesplash>
mjg: I try some basic benchmarking of compilation times when I make performance centric changes usually
<waddlesplash>
I didn't this time because I didn't really expect this was going to do anything in that regard
<waddlesplash>
maybe that was an incorrect assumption
rennj has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
cocobean has quit [Remote host closed the connection]
HaikuUser has joined #haiku
HaikuUser has quit []
<PulkoMandy>
Compilation does a lot of file creation/deletion in /tmp (if you don't set gcc to use a pipe to feed the assembler instead of files, at least)
<mjg>
you guys use clang or gcc
<mjg>
i can tell you for a fact clang creates and removes files for no reason