<B2IA>
(AGMS) Thanks Halian, the complication is I can't tell if the leakage is from inside the plastic window frame or the outer wooden siding. Having a day long blow of 60 to 80km/h winds does force water into all sorts of places!
<Begasus[m]>
Jookia it should fill your screen with some text output and a prompt
<Begasus[m]>
KDL*
<Jookia>
yeah it does that
<Begasus[m]>
OK, maybe you can try to make a screenshot (or take a picture) and file a ticket (if it's somehow related it will be marked as duplicate if it's a known thing)
<Begasus[m]>
did you try some safe mode options while booting?
<Begasus[m]>
also you could try if it continues when you enter "co" (continue) at the prompt
<Begasus[m]>
could be a qemu/32bit thing
<Jookia>
i'll have a look later. right now i'm trying to compile the latest haiku. can i install it from within haiku? :)
<Begasus[m]>
not an expert on that, maybe if you can mount it and launch the installer from within)?
<Begasus[m]>
mostly I only build 64bit here and launch a build with qemu to test drive those builds
<Begasus[m]>
reminds me I should look into getting that 32bit build fixed :)
<Jookia>
is haiku going to drop 32-bit x86 support some day?
<Begasus[m]>
hmm ... why do we still have a gcc2 "package" for lib:psqlodbcw ?
<Begasus[m]>
I don't think so, but I'm not part of that team :)
<Jookia>
i'm playing with OSes that run on older computers
<Begasus[m]>
goal is to still provide backwords compat for BeOS apps, so 32bit is still needed there
<Begasus[m]>
so I guess not before R1 :)
freddietilley has joined #haiku
WoC- has joined #haiku
WoC-- has quit [Remote host closed the connection]
GNU2Linux has quit [Quit: Connection closed for inactivity]
vdamewood has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Begasus[m]>
there, at least 32bit report is clean again
diver1 has joined #haiku
diver has quit [Read error: Connection reset by peer]
JakeSays1 has joined #haiku
JakeSays has quit [Ping timeout: 480 seconds]
JakeSays has joined #haiku
JakeSays1 has quit [Ping timeout: 480 seconds]
<Jookia>
can you update haiku in place using its build system?
<Begasus[m]>
not sure, iirc waddlesplash mentioned some time ago (been a while) to build haiku/haiku_devel and use pkgman to install those, but as mentioned, it's been a while so can't remember the details
<Begasus[m]>
and it's not even a full update
<Jookia>
oh
<Begasus[m]>
are you running nightly?
<Jookia>
no, this is on 32-bit so just the standard release. i tried to build the git code but it gave an error about icu
<Jookia>
or something related
<Begasus[m]>
ok, did you run an update after install? eg "pkgman full-sync" in Terminal?
<Jookia>
yes
<Begasus[m]>
you could alternative update your beta to a nightly (development in progress, so thing "could" brake in there)
<Begasus[m]>
now, if you could mention what error you got on ICU that would be a good first start
<Jookia>
it says it's not found. i'll have a bit of a look at it later, i'm not sure how invested i am in this if i have to reinstall or dual boot or something and can't install the build
<Begasus[m]>
did you made some local changes to the Haiku tree for the build?
<Begasus[m]>
if ICU is not found you are probably missing the _devel package
<Begasus[m]>
nice :) grabbing ffmpeg8-8.0.0-1-x86_64.hpkg and moving it to /Opslag/haikuports/packages/ffmpeg8-8.0.0-1-x86_64.hpkg
Aedil has quit [Quit: leaving]
<phschafft>
Good morning.
<Begasus[m]>
moin phschafft
<phschafft>
all good?
<erysdren>
moin moin
* phschafft
offers cookis to Begasus[m] and erysdren.
<erysdren>
nom!
<phschafft>
:))
<Begasus[m]>
thanks! :D
<Begasus[m]>
good here phschafft :) now checking kdenlive_master with ffmpeg8 :) you?
<Begasus[m]>
hi there erysdren (@_oftc_erysdren:matrix.org) :)
<phschafft>
doing a release of a perl module right now befor trying to write a mail to a customer.
<Begasus[m]>
keeping busy :)
<phschafft>
so, release is out the door. now mail and docs.
<nekobot>
[haiku/haiku] 6ec9699bb55f - Terminal: add support for DECRQM
<nekobot>
[haiku/haiku] 2858af6540af - Terminal: CSI REP min value is 1
<nekobot>
[haiku/haiku] 59a481a0498f - Terminal: support for overlined text
Aedil has joined #haiku
<phschafft>
so, documentation is also updated. :)
<Jookia>
why does haiku have POSIX compatibility?
<phschafft>
hm?
<phschafft>
I mean the answer is: because someone wrote it.
<phschafft>
but it feels like the question is actually about something else?
<Jookia>
no i'm genuinely just curious
<phschafft>
My guess is that POSIX is what everyone does. so if you are POSIX compatible you get a lot of software for free.
<phschafft>
which in the end means less work inside your own project, so less work for Haiku devs, more resources to spend on making it the best OS every and world domination and... and maybe some pizza!
<Jookia>
ah i see
bbjimmy has quit [Quit: Vision[]: i've been blurred!]
bbjimmy has joined #haiku
* |cos|
makes pizza every friday, not knowing it was due to haiku's posix support. now i know. thanks devs!
<Jookia>
oh yes i've seen that but i'm more wondering why
<waddlesplash>
why what?
<waddlesplash>
BeOS already was UNIX-y but didn't have a lot of the more useful APIs
<waddlesplash>
but those APIs aren't that hard to implement, and in fact many of them could be implemented on top of BeOS APIs anyway if you really had to, though with reduced functionality
<Jookia>
so it just happened organically?
<waddlesplash>
so Haiku just takes what BeOS was doing and goes much further in what it implements of POSIX
<Jookia>
nice
<waddlesplash>
Jookia: it's more like, why would we *not* implement the POSIX APIs?
<waddlesplash>
the alternative is having "sui generis" OS APIs, like Windows or certain parts of macOS
<waddlesplash>
and that makes apps way harder to port
<Jookia>
i'm not an OS dev so i just figured there was significant resources to add full POSIX support. i know NT didn't
<waddlesplash>
NT did, because NT is a pretty generic kernel AFAIK
itaipu has quit [Ping timeout: 480 seconds]
<waddlesplash>
it's just that it didn't ship with Windows by default but was an addon
<waddlesplash>
in recent years, NT's support for alternative process models and APIs was obviously revived for WSL1
<waddlesplash>
on Haiku though we don't have a "compatibility layer"
<waddlesplash>
it's just how the kernel actually behaves
<waddlesplash>
and well, yes, implementing POSIX APIs does take a lot of work, but what's the alternative? not implementing them?
<waddlesplash>
in many cases the POSIX-y API is the only way to do things on Haiku, so otherwise you wouldn't be able to do those things
<waddlesplash>
like mmap(fd)
<Jookia>
ah ok
<waddlesplash>
or (though this isn't POSIX but a BSD extension) kqueue()
hightower3 has joined #haiku
<waddlesplash>
some of these we could expose alternative APIs to the POSIX-y ones if we really wanted
<waddlesplash>
but in most cases there'd be no point
<phschafft>
and one good thing is there as well: you can implement things that are good in POSIX and skip others. that is the power of being an independent project.
<waddlesplash>
we have not skipped much
<waddlesplash>
wordexp() is the only thing I can think of
<waddlesplash>
there are POSIX APIs we haven't gotten around to, but they're just not too useful or weren't necessary yet
<x512[m]>
waddlesplash: I feel that half-implemented kqueue is a bad idea compared to Haiku-specific API or fully implementing kqueue. Many software detect kqueue support and become broken because of unsupported Haiku kqueue implementation. So it need even more patching.
<phschafft>
waddlesplash: I mean there is also a lot of deprecated stuff in POSIX (just because POSIX itself isn't really new ;)
<phschafft>
so it might be totally fine to skip those parts that might just be removed the next issue anyway.
<waddlesplash>
x512[m]: We've now shipped it for a full release cycle and not much stuff is broken by it, and it's easy to just disable it altogether in config checks. Meanwhile for the things that use it like libevent, it is a *huge* performance improvement
<waddlesplash>
if we got WINE fixed up again, it would also be a massive advantage there
<x512[m]>
waddlesplash: Is it hard to fully implement kqueue?
<waddlesplash>
the missing portions that most applications want is file monitoring
itaipu has joined #haiku
hightower2 has quit [Ping timeout: 480 seconds]
<waddlesplash>
this is hard to implement because kqueue's version is pretty different than Haiku's
<waddlesplash>
in most cases it would be better to just implement new backends for whatever wants it
<waddlesplash>
libevent and libuv at least split file/node monitoring from regular monitoring, or at least it's not hard to separate
<waddlesplash>
so we can use kqueue for FDs and processes, and a Haiku backend for node monitoring
<x512[m]>
There are still quite a lot places that use kqueue/epoll, Rust libraries for example.
<waddlesplash>
yes, well
<waddlesplash>
part of the difficulty here is that we can't do a lot in userland, we have to put it all in the kernel
<waddlesplash>
because kqueue FDs are disposed of with close()
<waddlesplash>
so we can't keep any extra state in userland
<waddlesplash>
it might be easier to implement a compatibility system for kqueue and vnodes if that wasn't the case
<waddlesplash>
I would really prefer not adding this to the event_queue that underlies kqueue directly, because that's Haiku-generic right now, it just takes FDs, ports, processes, etc.
<waddlesplash>
and vnode monitoring would be done via a port
erysdren has joined #haiku
<x512[m]>
If there are no plans to provide APIs other than kqueue, more implementation can be moved to kernel and libroot.so wrapper reduced.
<waddlesplash>
I mean, we might eventually
<waddlesplash>
could be useful to have alongside wait_for_objects
<waddlesplash>
x512[m]: I just re-read the manual page for kqueue. the vnode stuff is more different than ours than I remembered
<waddlesplash>
however, EVFILT_SIGNAL, TIMER, and USER should be possible to implement in the existing architecture
<x512[m]>
It have other stuff than node monitoring that is not implemented in Haiku.
<waddlesplash>
yes
<waddlesplash>
and that should mostly be implementable
<x512[m]>
Timer is useful.
freddietilley has quit [Quit: WeeChat 4.6.3]
OscarL has joined #haiku
<OscarL>
waddlesplash: got some "cpuid" dumps for the N4020 on baremetal, vbox, and vmware (3 .txt files: https://bpa.st/VKUA). (still need to check other machines for C-States support and such).
<OscarL>
Seems "mwait" does not get exposed in either vbox nor vmware, which I guess explains why I couldn't really notice an improvement with the changes you made around "KDL idling", right?
tuaris has joined #haiku
<waddlesplash>
yes
<waddlesplash>
this one should support x86_cstates on bare metal at least, right?
<OscarL>
indeed. checked yesterday, and both intel_cstates and intel_pstates drivers are loaded while on bare-metal.
<OscarL>
Begasus[m]: does "sys-apps" sounds like the correct cathegory for something like this little tool? (I mean... we have "dmidecode" in there, so...).
Arbuz555 has quit [Quit: Vision[]: i've been blurred!]
<Begasus[m]>
OscarL from the link that sound sane yes
<OscarL>
alright.
<OscarL>
we either need to include the ISC license in HaikuPorter, or figure out how to avoid getting the ISC from each package clobbered by other ISC files.
<Begasus[m]>
it's been discussed :)
<OscarL>
(I'd rather have a generic ISC in HP)
<Begasus[m]>
or in Haiku
<waddlesplash>
is the ISC license not identical to MIT?
<OscarL>
https://en.wikipedia.org/wiki/ISC_license "t is functionally equivalent to the simplified BSD and MIT licenses, but without language deemed unnecessary following the Berne Convention"
<OscarL>
oh, /me takes a looksie!
<OscarL>
waddlesplash: will pull and start some local build. Thanks!
<waddlesplash>
I tested it enough to verify it does find ACPI processor nodes correctly
<waddlesplash>
but it then fails init because it can't evaluate methods in QEMU of course
<waddlesplash>
and my hardware shouldn't use this anyway as it's all modern C-states
<waddlesplash>
so, you'll have to let me know what happens if it gets further
<waddlesplash>
init ends here with: "failed to eval _OSC and _PDC" then "no valid cpuidle module found"
<OscarL>
will prepare a pendrive and do a "tour" on at least: Atom N450, Atom N455, AMD E-450 today. Phenom II and Atom N2600 possibly for tomorrow.
<OscarL>
Mmm, Haiku already has ISC under system/data/licenses, but I still get "License 'ISC' isn't contained in package!" from HaikuPorter unless I include it. From where HP gets the list of valid licenses?
<waddlesplash>
the ISC license file probably comes from some package
<waddlesplash>
check its SYS:PACKAGE
<OscarL>
that's my issue, many recipes include that file. In my case... it nows comes from "abduco".
<OscarL>
so... the problem is not HaikuPorter, but "PackageWriterImpl::_CheckLicenses()" from PackageKit.
<waddlesplash>
the license likely doesn't exist in the chroot
<OscarL>
seems so. should the "haiku.hpkg" provide it then?
<waddlesplash>
yes, we can do that
<OscarL>
that'd be nice :-)
<OscarL>
anyway... back to compiling haiku, have some cstates to test! :-P
<waddlesplash>
it won't take effect until the next beta though
<waddlesplash>
for the builders
<OscarL>
understood. still better leaving it as-is for longer, I'd say.
<waddlesplash>
appears I added it with a cleanup of other things in January
<OscarL>
yeah, that was what I was referring with "Mmm, Haiku already has ISC under system/data/licenses," earlier.
<OscarL>
so, just need to wait for beta6 then, right?
<waddlesplash>
yeah
<OscarL>
(to hit the buildlers, of course)
<zdykstra>
mornin' all
<OscarL>
'lo zdykstra! :-)
<OscarL>
Launched haiku build.... "...updating 8132 target(s)..." /me goes watch some movie or something...
politebot has joined #haiku
<OscarL>
Since I switched from using mostly the Phenom to using moslty this N4020 based netbook... montly power usage went down from ~65 KWh to 35 KWh 8^0 (too bad that doesn't translate to meaningful $ saving due to fixed costs :-/)
mmu_man has quit [Ping timeout: 480 seconds]
vezhlys has joined #haiku
<glassnerves>
<OscarL> will prepare a pendrive and do a "tour" on at least: Atom N450, Atom N455, AMD E-450 today. Phenom II and Atom N2600 possibly for tomorrow.
<glassnerves>
Nice, my Thinkpad X120e running Haiku uses an AMD E-350
mmu_man has joined #haiku
<OscarL>
glassnerves: I was gifted a Lenovo C225 All-in-One as "e-waste" (the one with that E-450).
vezhlys has quit [Read error: Connection reset by peer]
<Begasus[m]>
closing down here
<Begasus[m]>
cu peeps!
<OscarL>
Be well Begasus[m]!
janking has joined #haiku
<Jookia>
can you add another partition to the boot loader in GPT mode?
<OscarL>
I don't think you "add partitions", but different (U)EFI bootloaders in the ESP partition.
<OscarL>
which gets picked up depends on efivars set on the BIOS, or if you use something like rEFInd to automagically manage your different bootloaders.
<Jookia>
i used GPT without UEFI
<OscarL>
(some OSes do alter the efivars on installation, Haiku does not. Some BIOS seem to pickup at least bootloaders named "bootx64.efi", and you can choose them from either BIOS/EFI or a boot-time selection menu)
<OscarL>
Jookia: so you're booting into BIOS/Legacy mode. I guess you should be able to use any MBR boot manager then, and that should allow you to chain load other PBR (partition boot records).
<Jookia>
haiku has its own boot manager though that the system is booting from
<OscarL>
Haiku has "BootMananger". I use that on all my BIOS systems to manage the main boot menu. It allows me to chain load/boot Win10, Linux, etc.
<Jookia>
yeah, that doesn't work with GPT
<OscarL>
I guess Bootmanager "chokes" when it finds a GPT drive, then, right?
<Jookia>
no, it says it's incompatible
<OscarL>
Welp, guess you could try some version of GRUB, and then chainload Haiku from it. Or try some other bootmanager, like "plop", perhaps, but I don't have much experience with those.
<Jookia>
well i'd have to reinstall wouldn't i
<OscarL>
I kinda have the other way around.... have an MBR style SSD, with an ESP partition... on all machines with BIOS/Legacy mode... can boot no problems. on one with UEFI... It kinda loads rEFINd, and then can UEFI boot Haiku from it. on this machine (UEFI only), can't boot from that drive :-D
<Jookia>
it also looks like trying to build gives errors about missing icu, webkit libdvdread libdvdnav libraw libavif, gutenprint qrencode_kdl libdvdread libdvdnav libraw
<OscarL>
Jookia: I *think* you might have been missing "gcc_syslibs_devel" or have missmatched versions (I'd use "pkgman full-sync" and a reboot before retrying to closely follow the build instructions again).
<Jookia>
that doesn't help. i think i'll just give up on developing for now
<OscarL>
I don't remember having much problems building Haiku, other than once or twice where I had updated gcc, but somehow had older syslibs for it.
<Jookia>
this is the 32-bit haiku
<Jookia>
maybe it's bitrotted
<OscarL>
I do use both 64 and 32 bits.
<Jookia>
do you build using a 32-bit image/vm?
<OscarL>
granted, haven't done a 32 bits build latelte, but I could try tomorrow (this hardware is SLOW, and still waiting for a 64 bits build).
<OscarL>
s/latelte/lately/
<Jookia>
i did try to cross-compile from arch but that doesn't work for 32-bit builds
<OscarL>
Jookia: I use the same installs in bare-metal and under VMs (Vbox and VMware)
<OscarL>
building Haiku 32 bits under Haiku 32 bits should be the easiest, as you don't need to build separate buildtools as on 64 bits (unless you disable the building of the 32 bits bootloader code).
<Jookia>
yeah, that's what i thought. apparently not
HaikuUser has joined #haiku
HaikuUser is now known as scantysnax
<OscarL>
you may be missing something simple. easy to get things wrong with unfamiliar systems.
<PulkoMandy>
For 32 bit you have to use gcc2 as the main compiler (by passing the right options to the configure script)
<Jookia>
on linux? or haiku?
<PulkoMandy>
32 bit without BeOS compatibility support is indeed abandoned and bitrotted
erysdren has quit [Quit: Konversation terminated!]
scantysnax has quit []
<PulkoMandy>
when building from linux the configure script will build a cross compiler that targets haiku
<Jookia>
yes i told it to do that but that didn't work, it just said gcc doesn't work
<Jookia>
i assume this is because arch can't compile for 32-bit systems or something
<PulkoMandy>
maybe, or maybe a too new version of gcc that we don't handle yet (I think gcc13 is supported, newer ones may not be yet)
<Jookia>
it said gcc couldn't produce a valid binary or something
<Jookia>
i think it assumes its a multilib gcc
<Jookia>
oh well, if 32 bit support is abandoned/bitrotted then i don't have a use for haiku atm :\
HaikuUser has joined #haiku
<PulkoMandy>
possibly yes. I don't remember the tricks we do to build gcc2 on modern 64 bit systems but it may be using multilib and building as 32bit
<PulkoMandy>
It isn't, we have nightly builds, and it is actively maintained
HaikuUser is now known as scantysnax
<Jookia>
oh
mmu_man is now known as Guest26278
<Jookia>
well if someone manages to build haiku in a 32-bit system could they ping me with instructions?
mmu_man has joined #haiku
<OscarL>
Jookia: Haiku still works on 32 bits just fine. Only one variant of "32 bits" is not used anymore (the one without BeOS compatibility)
<OscarL>
rebooting to test waddlesplash's "hrev59042+1+dirty" :-D
<PulkoMandy>
no time to look today I think :( I have to leave in a few minutes... and also I would do it on debian since I don't have arch at hand. But I can at least check that and make sure the build instructions still work (I usually work from Haiku so I'm not the best oerson to ask for building from linux support)
Guest26278 has quit [Ping timeout: 480 seconds]
<Jookia>
i was building from haiku
<Jookia>
i tried linux as an alternative and that didn't work either
<OscarL>
Jookia: From Haiku 32 bits... besides cloing the haiku repo... then you should only need to run "./configure" and then "jam -q -j $(nproc) @nightly-raw haiku.hpkg haiku_devel.hpkg" (to just build the main packages).
<OscarL>
you may want to create separate "generated" directories for 32 and 64 bits, if needed (and then run "./configure" from inside those dirs, and not from the root dir), but other than that... I don't recall having to do much.
<Jookia>
then i use the install command to install it to the second partition?
<OscarL>
you can install/update those packages in-place.
<Jookia>
ah, it says i'm using a haiku clone without tags
<Jookia>
i'll set the revision to hrev43210 like it says
<OscarL>
you either need to clone from review.haiku-os.org (as the instructions say), or "fake" the hrev, but I don't recall how to do that.
<OscarL>
anyway... see you all in a bit (hopefully)! (reboots)
OscarL has quit []
OscarL has joined #haiku
<waddlesplash>
Jookia: what error are you hitting exactly?
<waddlesplash>
I build on 32-bit now and again, works just fine
<Jookia>
waddlesplash: i don't know, it was a while ago, it said some targets failed
<waddlesplash>
okay, well, I need a more specific error to diagnose lol
<waddlesplash>
what are you trying to build Haiku for anyway?
<Jookia>
for fun
<waddlesplash>
lol okay
<waddlesplash>
well, the process is much less painful than trying to build Linux or something like that, but it's still a bit complicated sometimes
* waddlesplash
has been meaning to rewrite ReadMe.Compiling.md for clarity at some point but hasn't
<Jookia>
i do lots of linux building so i'm more use to the process. things like buildroot make it very easy :D
itaipu has quit [Read error: Connection reset by peer]
<glassnerves>
><OscarL> glassnerves: I've got a very simple temp driver that should work on your E-350: https://github.com/OscarL/amd_temp
<glassnerves>
Thanks, I will try =)
<Jookia>
is theri would like to try running haiku on a pentium 3 but i'd like to be able to get fixes for it so that means compiling the dev branches
<waddlesplash>
fixes for what?
<Jookia>
bugs in haiku
<waddlesplash>
you can just use the nightly updates channel?
OscarL has quit [Quit: Gone with the wind]
<waddlesplash>
you can build if you want, but it's not necessary, the nightly builds track the master branch
<Jookia>
i'd also like to try fixing some bugs :)
<waddlesplash>
ah
<Jookia>
i already found one so might as well try
<waddlesplash>
what one?
<waddlesplash>
and you can 32-bit Haiku on Linux so long as you can build GCC2 in 32-bit mode
<waddlesplash>
*you can build
<Jookia>
i can't do that on arch
<Jookia>
r5 fails to boot on 32-bit with 4gb of ram
<waddlesplash>
works fine with way less than that here
<waddlesplash>
what happens?
<Jookia>
it faults in some driver
<waddlesplash>
screenshot?
<Jookia>
i don't have one, sorry
<waddlesplash>
...
<waddlesplash>
well, come back when you have one :P
<waddlesplash>
32-bit R1/beta5 should boot in 512MB, maybe even 384MB
<Jookia>
i said 4gb
<waddlesplash>
nightlies got a bunch of memory fixes, they should be able to boot in 128MB
<waddlesplash>
Jookia: I routinely boot 64-bit Haiku in 1GB without problems, the memory amount isn't the issue here
<Jookia>
4gb is the maximum address size of a 32-bit system
<waddlesplash>
nope!
<Jookia>
for physical memory addressing
<waddlesplash>
nope!
<Jookia>
idk what to say then
itaipu has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
<waddlesplash>
Jookia: x86 with PAE supports up to 36 bit addresses, so 64 RAM
<waddlesplash>
*64 GB
<Jookia>
yes but it still only has 32 bits of addressing
<waddlesplash>
32 bits of *virtual* addressing
<Jookia>
yes
<waddlesplash>
you can use more than 4GB of RAM at a time on such systems though
<waddlesplash>
and Haiku does support PAE, so it works for us
<Jookia>
that doesn't make your pointers not wrap around
<waddlesplash>
how would pointers "wrap around"?
<waddlesplash>
the 32-bit Haiku kernel uses 64-bit physical pointers on x86
<waddlesplash>
to accomodate the 36-bit physical addresse
<Jookia>
i don't know what to tell you then
<waddlesplash>
whatever crash you encountered is probably unrelated to all this
<waddlesplash>
and is just some other unrelated bug
<Jookia>
it's unrelated to the memory size being 4gb? despite setting it to 2gb fixing it?
<waddlesplash>
... you could have lead with that detail lol
<waddlesplash>
anyway it's still probably unrelated to 32-bit vs. 64-bit strictly speaking
<waddlesplash>
there were a number of odd memory management issues in the bootloader/kernel handoff sequence that were fixed since beta5 on the nightly builds
<Jookia>
i assume people are running more than 4gb of ram on a 64-bit system?
<waddlesplash>
I boot Haiku on bare metal with 32 GB of RAM
<waddlesplash>
so yes
<waddlesplash>
but in the process of testing those bootloader/kernel fixes some months back, I also booted the 32-bit build with 64 GB RAM
<Jookia>
yeah so it's something that isn't working on 32-bit but probably works on 64-bit and it's related to the size of memory addressing and causes a kernel fault during a memcpy or something
<waddlesplash>
after the fixes, it worked fine
<waddlesplash>
is it even a kernel fault?
<Jookia>
it gives the kernel debugger
<waddlesplash>
it could be an assertion failure or some other error, not a fault per se
<waddlesplash>
yes, but that comes up for more things than page faults
<waddlesplash>
without the message it printed I can't tell you more
<waddlesplash>
and a lot of the possible problems here were solved on the nightlies after beta5
<waddlesplash>
so, it may be that there's nothing to debug because we already fixed it :P
<waddlesplash>
Jookia: what QEMU command line are you using?
<Jookia>
i don't know
<waddlesplash>
and yes, please try with a nightly to see if this goes away. The nightlies do contain changes that could affect this
OscarL has joined #haiku
<waddlesplash>
Jookia: if you're using virt-manager or something like that there's ways to get the command line from it
<scantysnax>
Hi there OscarL!
<OscarL>
Hola scantysnax! :-D
<scantysnax>
how are you feeling today?
<OscarL>
scantysnax: slowly getting better at last it seems (/me knocks on wood), thanks for asking! (Albeit the bed is already looking tempting and is not even 15:30 here :-D).
<scantysnax>
glad to hear you're feeling better. bed looks tempting when i get home a bit after 16:00
<Jookia>
i did a search in the bug tracker earlier today and didn't find this stack trace
<OscarL>
waddlesplash: no luck on the N455. "power/cpuidle/x86_acpi_cstates/v1 failed!", so I guess not much point in testing the N450 then :-). Will try on the AMD E-450 next.
<waddlesplash>
OscarL: whole syslog please
<waddlesplash>
or at least the lines right around that
<waddlesplash>
they ought to contain a useful error
<Jookia>
nightly crashes too
<waddlesplash>
interesting
<OscarL>
not really. some line got overwritten. In any case.... will save clean syslog, and upload later (these machines are not networked).
<waddlesplash>
OK
<OscarL>
for some reason, it this hrev doesn't powers off by itself (leaves it as "It's now safe to turn off the computer"), on both the N455, and on VMware over the N4020.
<waddlesplash>
hm
<waddlesplash>
sounds like something went wrong with ACPI
<waddlesplash>
check the syslog after a reboot, probably
<waddlesplash>
that may also explain why it failed to initialize the cpuidle driver...
<OscarL>
rebooting to get clean syslog from the E-450-
* scantysnax
is excited today. new battery arriving for my Haiku laptop :-)
<OscarL>
yeah, lots of acpi related errors. will try to upload files next.
<OscarL>
scantysnax: nice :-)
<OscarL>
e-450 won't power off either. at least it is consistent :-)
<waddlesplash>
KERN: ACPI Error: Could not remove SCI handler (20250404/evmisc-424)
<waddlesplash>
that's your problem
<waddlesplash>
the new driver does use ACPI but it nothing should've changed otherwise...
<waddlesplash>
the driver doesn't load till quite late in the boot process
<waddlesplash>
with the "chip" icon in the bootsplash
<waddlesplash>
OscarL: try nuking your ACPI objects directory and rebuild
<OscarL>
maybe my build got borked for some reason?
<waddlesplash>
oh wait
<waddlesplash>
OscarL: are you using a beta5 bootloader package lol
<waddlesplash>
if so, then that explains it
<waddlesplash>
you need to upgrade to a nightly bootloader
<waddlesplash>
just rebuild haiku_loader.hpkg and install it, too
<OscarL>
ah, could be. welp... that will be a problem, I don't have buildtools (and not going to build that on this anemic hardware. Guess I will have to wait till after 22:00 to be able to download the test builds.
<Jookia>
waddlesplash: 'mapping' for the invalid source address shows its looking for phys address 0x100000120 i think
<waddlesplash>
OscarL: you don't have any nightly installs?
<waddlesplash>
Jookia: doesn't really explain why this goes wrong
<waddlesplash>
I'm poking around in qemu to see if I can reproduce
<OscarL>
seems the bot alread has haiku_loader.hpkg, and that's small enough, downloading that one now.
<OscarL>
waddlesplash: have a nightly, but is 32 bits. might have some 64 bits one somewhere, but most likely pretty old. Let me try this haiku_loader.hpkg I got from the bot :-)
<OscarL>
(goodby "Haiku logo" at boot... there's some slight drawing glitch when there's no logo)
<OscarL>
vmware powered off correctly now. let's test the N455 again.
<OscarL>
N455 seems stuck on the rocket icon now.... aaaand PANICked "no more request for owner" around "usb_disk scheduler 2". Maybe a bad USB port... retrying.
scantysnax has quit [Ping timeout: 480 seconds]
<waddlesplash>
OscarL: that looks like an assertion failure. you can just continue it I think
<OscarL>
probably just this crappy usb-adaptor. collected clean syslog (didn't saw any mention of cstates though). Moving to the E-450, and then will upload.
<waddlesplash>
nah, that panic looks like some leftover debugging code
<waddlesplash>
it's interesting that it doesn't seem to be triggered much
<OscarL>
this particular usb-sata adaptor already killed one hdd before so... :-D (seems I like playing with fire).
<waddlesplash>
Jookia: SMBIOS inits OK here, QEMU 10 (no KVM tho)
<waddlesplash>
I copied as much of your command line as I could
<waddlesplash>
what do you get for the SMBIOS scan?
<Jookia>
waddlesplash: i think i can confirm by inspection that the problem is a false table is being found and used. verifying the table is correct using its checksum would fix this
e1z07567351 has quit []
e1z07567351 has joined #haiku
<OscarL>
waddlesplash: output of cpuid for the Atom N455: https://0x0.st/KbS6.txt (mwait AND c-states mentioned 8-/)
<waddlesplash>
does that one use the C-states driver?
<waddlesplash>
seems not
* waddlesplash
adds some logging
<OscarL>
not according to the syslogs, and listimage 1.
<waddlesplash>
if you installed haiku_devel.hpkg locally, then it is probably rebuilding all the host tools
<OscarL>
I didn't even switched branches :-(ç
<waddlesplash>
because the system headers times changed
<OscarL>
ah, that explains things :-)
<waddlesplash>
and then it rebuilds all the things those rely on
<waddlesplash>
some of them are the mime_db and the like, which is fast to update
<OscarL>
"fast", heh... you overestimate my hardware :-P (thanks for the UserBuildConfig tip... will proceed to add that one now)ç
<Jookia>
i'm off to sleep. i hope tomorrow i'll finally get a good haiku setup. maybe i can try fixing the smbios bug
<waddlesplash>
OscarL: just pushed new version of the acpi_cstates patch that should fix the failures to init
<OscarL>
let me cancel the build then.
<OscarL>
Should I still apply the x86_cstates.diff on top of your latest push, right?
<waddlesplash>
yes
e1z07567351 has quit []
e1z07567351 has joined #haiku
<OscarL>
starting new build (with HAIKU_PACKAGE_COMPRESSION_LEVEL = 1 ! :-D)
jmairboeck has quit [Read error: Connection reset by peer]
<waddlesplash>
Jookia: switched to PAE, still no crash. Well, I guess we'll see what you come up with
<waddlesplash>
Jookia: however, vm_memcpy_from/to_physical should *never* fault, anyway
Aedil has quit [Quit: leaving]
<waddlesplash>
or rather, if it does, it's the caller's fault for passing an invalid non-physical address
<waddlesplash>
the physical side should never fault
<waddlesplash>
Jookia: and looking at that code in smbios.cpp the passed local address is from a malloc(). So it'll be the right size. So, this should never, ever fault, and if it is, there's a bug elsewhere than the SMBIOS module
<Jookia>
waddlesplash: i looked at the registers earlier and assuming the memcpy is being optimized in to a rep movsb or something, di is correct, si is the problem, so the table physical address
<waddlesplash>
how are we faulting on a physical address?
<waddlesplash>
does that page just not exist in the physical memory?
<Jookia>
i'm not sure, i don't know much about MMUs. i know the address is greater than 32 bits and i don't have PAE so maybe that's a factor? is there a way to test this or gather more info tomorrow?
<waddlesplash>
yes you do have PAE
<waddlesplash>
it's in the log you posted
<waddlesplash>
"using PAE paging"
<Jookia>
oh, interesting
<waddlesplash>
there should be a dump of the memory map somewhere
<waddlesplash>
indicating the physical ranges
<waddlesplash>
you can check if the requested physical address exists in them
<waddlesplash>
(ignore the ENABLE_SERIAL comment, it's already enabled)
<Jookia>
alright, shall do that tomorrow or this weekend
<waddlesplash>
very good
<waddlesplash>
thanks for investigating!
<Jookia>
FWIW i'm only very familiar with 32-bit ARM systems with no address extension :(
<waddlesplash>
lol, well, maybe you can help us with the ARM port :)
<waddlesplash>
the 32-bit ARM port in QEMU can get almost to the desktop
<Jookia>
perhaps. i think 32-bit ARM is on its way out
<waddlesplash>
64-bit gets past mounting the boot filesystem, I don't know how much further than that
<waddlesplash>
but the syscall interface isn't written yet
<phschafft>
good morning.
<Jookia>
the area i hang around in where 32-bit is applicable seems to be leaning towards moving to 64-bit risc-v instead of paying for 64-bit arm licenses
<Jookia>
risc-v is kind of consuming the low-end market
<waddlesplash>
by "almost to the desktop" I mean davidkaroly (last developer who worked on it) posted a screenshot of Haiku running in QEMU with a blue screen and a crash dialog
<waddlesplash>
so, userspace does start and at least partially worked
<waddlesplash>
Jookia: Haiku on RISCV64 boots to desktop and runs, only other platform besides x86 where it does
<waddlesplash>
it doesn't support too much hardware at present though
<Jookia>
that's good news
<waddlesplash>
we have a builder that runs on the SiFive Unmatched at least
<Jookia>
i'm not sure how much effort is appropriate to put in to arm32 at this point tbh
<waddlesplash>
yes, that's fair
<waddlesplash>
the focus more recently was on the arm64 port
<waddlesplash>
it just needs more work
<Jookia>
is this in QEMU or real hardware?
<waddlesplash>
arm is all qemu
<waddlesplash>
riscv works in both
<waddlesplash>
however, arm64 is more standard than arm32, and I know the rpi4 has XHCI attached to a good ol' PCI bus?
<waddlesplash>
and XHCI does work on RISCV including bare metal and at least to some degree in QEMU for ARM64
<waddlesplash>
so we are not doing so bad there
<Jookia>
that's pretty good
<Jookia>
i would expect it just to be an issue of setting up a device tree and bringing in drivers for the hardware
<waddlesplash>
once the OS is ported, yes
<waddlesplash>
but the arm64 port is incomplete, like I said, so
<waddlesplash>
anyway I mostly stick to x86 because that's what everyone uses, and I'm actually paid to work on Haiku so I try to stick to useful stuff :)
<waddlesplash>
if we got a working ARM64 port and there started to be a sizable segment of people running Haiku on ARM, I'd probably have to acquire some hardware for myself to be able to work on it
<waddlesplash>
OscarL: any luck?
<OscarL>
not getting anything more than "no valid cpuidle module found" :-(
<waddlesplash>
that shouldn't be happening
<waddlesplash>
if you applied the new changes, you should get more prints
<waddlesplash>
at least on N455
<OscarL>
on the N455 at the moment, trying to double check what changes I have on the tree I just built.
<waddlesplash>
and with the change to the acpi_cpuidle module, it should get further in init
<Jookia>
right now i'm kind of just interested in what i can use on retrocomputers (i586+ and armv7). it might be a losing battle though there. i spend too much time thinking about the past instead of the future it seems :)
<waddlesplash>
well, Haiku should work well on i586+
<waddlesplash>
armv7 was indeed the target for the arm32 port
<waddlesplash>
and we definitely do much better than Linux on low-end hardware
<OscarL>
"git show" shows the same commit sha1 as the one from gerrit (patchset 3), and I did "git apply" the other .diff
<phschafft>
i586+ is now considered retro?
<Habbie>
phschafft, yes
<Jookia>
in linux land, you can barely get a 32-bit x86 system going
<OscarL>
(changes on x86_cstate.cpp are indeed there)
<phschafft>
I mean I think I have like what I consider retro and then 'current' systems. somehow I have that gap in perspective.
<Jookia>
anyway goodnight! :)
<phschafft>
nachti Jookia!
<OscarL>
sleep well Jookia!
<OscarL>
I'm nuking power/cpuidle from generated, and attempting a new build.
<phschafft>
I was actually thinking about booting one of the old machines today.
<OscarL>
typo on the PANIC... "wasn´t" vs "wasn't" :-P
<OscarL>
(in the actual KDL message, I mean)
<OscarL>
now, let's see if I can boot again from this drive (first attempt after the KDL just hang on the rocket icon)
<OscarL>
was able to boot from VMware on the N4020. nice. running checkfs revealed some "X blocks could be freed", but nothing else. pheew.
absyn-th has joined #haiku
<OscarL>
waddlesplash: I've nuked "generated.x86_64/objects/haiku/x86_64/release/add-ons/kernel/power/cpuidle", given that I still see the same sha1 as in +/9637/ (PS3) and I got "x86_cstates.diff" applied... "jam"ing haiku.hpkg again should be enough, right?
<waddlesplash>
yes
<OscarL>
(to be sure I'm using the right patches, I mean)
<OscarL>
alright... let's rebuild, just in case then.
<OscarL>
all seems OK after a reboot on VMware. Will test the N455 once more.
<waddlesplash>
I have a fix for the acpi cpuidle driver
<waddlesplash>
hopefully this will get it a bit further
<waddlesplash>
but it's strange we get no more log prints from the other one
<waddlesplash>
maybe I need even more debug statements because it's bailing out even earlier?
<OscarL>
bleh... got some KDL again on the N455 (seems related to media_addon_server... I should have kept hda blacklisted)
<OscarL>
the slower the hardware, the easier to get either crashes on media_addon_server at boot, or straight KDLs, like right now.
<waddlesplash>
the crashes I have an idea about how to investigate
<waddlesplash>
KDLs I don't know about. Is that reported?
<waddlesplash>
the open tickets are about crashes
<OscarL>
the screen on this thing is tiny, and KDL "folds over itself", so it gets harder to read. but hda and media_addon are clearly there.
<waddlesplash>
is it continuable?
<waddlesplash>
will be quite annoying to debug if not
<OscarL>
now I think I'm experiencing again the "random" failure to boot with SMP enabled on Atom N45x.
<OscarL>
tried "co" a few times... didn't got anywere.
<OscarL>
PANIC: no more requests for owner 0xFFF.... (thread 7)
<waddlesplash>
that one should be continuable
<OscarL>
again with the "usb_disk scheduler 2"
<OscarL>
let's see.
<OscarL>
"co" just sends me back at the same panic, apparently.
<OscarL>
(tried a few times)
<waddlesplash>
ugh
<waddlesplash>
well, I'll work on that one later
<OscarL>
sorry for giving you so much work :-)
<waddlesplash>
updated patchset on gerrit
* OscarL
tries rebooting with SMP and hda disabled.
<waddlesplash>
and new patch with all exits logged
<waddlesplash>
for the regular cstates
<OscarL>
you write patches faster than either my CPUs or my brain can process :-)
<waddlesplash>
lol
<waddlesplash>
the new version of the gerrit change includes some edits to the kernel that I'm not so sure about... I'll have to check some things before deciding if I want to implement it that way
<waddlesplash>
but, it works in QEMU to match ACPI CPU IDs
<waddlesplash>
so it should work on your hardware too, hopefully
<waddlesplash>
for the moment
<OscarL>
thanks a bunch for giving this a try.
<OscarL>
I might be slow, but will do my best to test things.
<OscarL>
bleh.... with hda and SMP disabled.... got stuck at the memory chip. first time I see that, LOL.
<OscarL>
to be fair.... N455 are kinda cursed. Will do a quick test on the N450 if I can find it.
<OscarL>
this feels like bringing up the big guns... this one has 2 GB of RAM!!!
<waddlesplash>
OscarL: memory chip is where CPUidle gets initialized
<waddlesplash>
if it stalled there, then that probably means it actually tried to activate CPU idle
<waddlesplash>
try booting with onscreen debug enabled
<waddlesplash>
and see where output stops
<OscarL>
alright. will keep that in mind (re on screen debug)
<OscarL>
the N450 progressed to desktop.
<OscarL>
heck, even autoconnected to wifi, LOL :-)
erysdren has joined #haiku
<OscarL>
still nothing more than "no valid cpuidle module found" (this is still only with patchset 3 + x86_cstates.cpp.diff)
<OscarL>
(I'm having a really bad time switching from "this" screen and the tiny ones on the netbooks back and forth. I used to have such good eyes... till about 3 or 4 years ago. Now I get dizzy changing eye-glasses :-D)
<erysdren>
hola OscarL
<OscarL>
cpuid info between N450 and N455, only varies in the processor's name.
<OscarL>
aloha erysdren! :-D
<OscarL>
liked reading about pak files on your site the other day :-). Made me remember when my room-mate and I wrote our own id3 tag editor, by just deducing what the format was back in 99 (if I can trust my recollection of dates so far back).
<erysdren>
i love file format reverse engineering :3
<erysdren>
this morning i wrote a Blender plugin to export 3D Studio VUE animation files
<erysdren>
it's just an ASCII script file format, but i thought it was interesting
<erysdren>
it's very scarcely documented, i can't even find a proper spec except for an old document on the 3DS Max website
<erysdren>
i actually can't tell if it's related to the landscape creator tool named Vue haha
<erysdren>
my earliest sample VUE file is from 1993
<OscarL>
every bit helps, even if you never hear about people reading what you wrote. If you have the right inclination... please continue to document your findings.
<OscarL>
(that goes for everyone reading, not just erysdren)
mmu_man is now known as Guest26289
<erysdren>
i might write a post on VUE files then
mmu_man has joined #haiku
<erysdren>
ahh, i found some more docs while using tougher Google search terms. apparently it was the 3D Studio standard animation format back in the early 90s. it was used for Star Wars Dark Forces somehow
<OscarL>
re: id3tags... we didn't had any other choice but to figure it out ouselves :-D... we got some mp3s and Winamp via "sneaker net" (at the ends of 1997 at first). mp3s with tags came later, but internet access was expensive/limited so it was cheaper to figure things out on our own. My friend and I still used our editor well into the late 2000s :-D
<FreeFull>
Back when you paid for each minute you were online
Guest26289 has quit [Ping timeout: 480 seconds]
<FreeFull>
And couldn't make phone calls at the same time
<OscarL>
FreeFull: and that's why I loved "Charisma & Stamina" software for BeOS... I used to log in... browse things as fast as I could for about 15 minutes... and then read things "offline" thanks to the mentioned Charisma & Stamina software (that cached whatever you browsed, and then, when internet was down, acted as a trasparente proxy).
<OscarL>
but that was already in 2003-2005, once I left Uni, and found a PCTel Winmodem that worked with BeOS! :-)
<FreeFull>
Hm, by 2005 we had ADSL
<FreeFull>
Probably by 2000 already or so
<OscarL>
FreeFull: to give you an idea.... I had 56K dial up till ends of 2005. Then I moved across country, and didn't have internet at home till ends of 2020 :-(
<FreeFull>
Jeez
<OscarL>
(and now I'm back at using cell "phone" for internet access :-D)
<FreeFull>
LTE?
<FreeFull>
Tell me it's at least LTE
<OscarL>
yes, very speedy, but expensive and limited to 2 GB per month :-(
<FreeFull>
Oof
<FreeFull>
2GB really isn't a lot in 2025
<OscarL>
it certainly is not. To be "fair".... I get "500 MB" "free" per night (22:00 to 6:00 if I'm awake) with that 2GB/month package but... bewteeen Windows/Android assuming you have flat rate access, and having to match my crazy sleep schedule with those hours...
<OscarL>
not ideal :-)
<OscarL>
on the other hand... I half-joke that this channel has benefited since I have to pay for every word I type :-P
<OscarL>
(whatever it takes to make me shut up... can't be that bad, type of thing :-D)
<OscarL>
erysdren: I don't remember when or where I read "this" but... the point was that you for any person you get actual feedback from... there's a whole universe of people that read your stuff that never got to share their feelings (both "positive" or "negative"). Making a long story short. Make whatever you do as freely available as you can. Let other's figure out if is "good" or not.
<OscarL>
waddlesplash: thanks!
<erysdren>
thank you OscarL, that means a lot!
<erysdren>
i try to ignore what people think and do what i do... but its hard
<OscarL>
erysdren: "this is what I got to share" mentality ain't never a bad thing (contrary to "this is how things should be" types). Your site reads like the former, thus... I like it a lot.
politebot has quit [Quit: Vision[]: i've been blurred!]
neoncortex has joined #haiku
diver1 has left #haiku [#haiku]
diver has joined #haiku
<OscarL>
waddlesplash: I can't see straight anymore. Will attempt testing when I wake up again. Thanks a bunch for your work. As always... very much appreciated!
<waddlesplash>
:)
<erysdren>
you leaving OscarL?
<erysdren>
if so, have a good night!
<OscarL>
I can stay for a while, if needed. but I can't be trusted with proper testing :-D
<OscarL>
yeah... seems I can't focus the screen anymore today, so... here's me hoping to read you all soon, my good people!