| KREYREN | Is there a way to write the OS to the N900's internal storage somehow? | 01:11 |
|---|---|---|
| * KREYREN is trying to figure out a deployment method for nixos where his infrastructure management deploys OS directly to the drives for purity | 01:12 | |
| sicelo | KREYREN: easiest way would be to partition the internal storage, then have an u-boot config that will point to that. you probably don't want to remove Maemo | 07:22 |
| sicelo | anyway, we generally prefer SD cards since they're (likely to be) much faster than the emmc. | 07:23 |
| freemangordon | Wizzup: ok, it is not only mafw | 07:59 |
| freemangordon | actually paplay does not work right after reboot here | 07:59 |
| freemangordon | [pulseaudio] shm.c: mmap() failed: Cannot allocate memory | 08:00 |
| freemangordon | seems we hit some shmem limit | 08:00 |
| freemangordon | https://pastebin.com/GA00WiSr | 08:01 |
| freemangordon | this is from paplay | 08:01 |
| freemangordon | pulseaudio has 45 shmem maps and that seems to be the limit | 08:04 |
| freemangordon | ok, so 45*64MB = 2880MB, ~3GB, which is basically the max 32 bit address space, no? | 08:11 |
| freemangordon | so, does anyone know what would be the issue if we reduce shm-size-bytes to 8MB or something? | 08:40 |
| freemangordon | heh, on fremanlte shm is disabled :D | 08:42 |
| freemangordon | I think we shall use https://man.archlinux.org/man/pulseaudio.1.en#disable_shm | 08:47 |
| sicelo | thanks Wizzup (@ merging) | 08:57 |
| Wizzup | freemangordon: interesting @ shm... | 10:52 |
| Wizzup | Please note that data transfer via shared memory segments is always disabled when PulseAudio is running with --system enabled (see above). | 10:52 |
| Wizzup | fremantle was running in system so yeah | 10:52 |
| Wizzup | freemangordon: but why do we hit this limit | 10:53 |
| Wizzup | ah, I see... | 10:53 |
| freemangordon | because we are 32 bits :) | 11:07 |
| freemangordon | Wizzup: not only fremantle is running with --system, shm is also disabled in client.conf | 11:08 |
| freemangordon | on fremantle that is, check it | 11:08 |
| Wizzup | but system disabled shm | 11:20 |
| Wizzup | disables | 11:20 |
| Wizzup | but yeah we can control client.conf changes | 11:20 |
| Wizzup | want me to try? | 11:20 |
| freemangordon | I've already disabled shm here and everything looks fine so far | 11:27 |
| freemangordon | but, we have the option to not allocate 64MB VM space per client | 11:28 |
| uvos__ | why would it be holding so mutch shm anyhow | 11:28 |
| freemangordon | it does not | 11:28 |
| freemangordon | it just allocates the space | 11:28 |
| uvos__ | would not a couple of meg per client be enough | 11:28 |
| uvos__ | ok | 11:28 |
| freemangordon | I don;t know, was about to ask :) | 11:28 |
| uvos__ | but why dose it allocate all the this space | 11:28 |
| freemangordon | this is the default | 11:29 |
| uvos__ | sure i get that but i dont understand under which circumstances this would be benefital | 11:29 |
| uvos__ | i gues we need to ask pa devs | 11:29 |
| freemangordon | I was not able to find anything useful in inet | 11:30 |
| uvos__ | we dont really want to disable shm ofc | 11:30 |
| uvos__ | since it saves cpu time over using the socket | 11:30 |
| freemangordon | shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB | 11:30 |
| uvos__ | iirc enableing shm (via loss of system) was what a factor that made call audio tollerable on n900 | 11:31 |
| uvos__ | freemangordon: ok yeah we can just make it smaller thne | 11:31 |
| freemangordon | yeah, but how much? | 11:31 |
| uvos__ | i gues we mesure how mutch it uses | 11:32 |
| freemangordon | there is absolutely no explanation what this is used for | 11:32 |
| freemangordon | no, as it deletes /dev/shm files | 11:32 |
| freemangordon | so we don't know the real size | 11:32 |
| uvos__ | iiuc its used to transfer samples | 11:32 |
| freemangordon | and I am not sure what to check in /proc/$pid | 11:32 |
| uvos__ | ok ill see if i can figure it out | 11:33 |
| freemangordon | but yeah, I guess we can make it 1MB and see if it is ok | 11:33 |
| uvos__ | otherwise lets ask #pulseaudio on matrix | 11:33 |
| freemangordon | do I need account fo that? | 11:34 |
| freemangordon | *for | 11:34 |
| freemangordon | see https://github.com/gavv/gavv.github.io/blob/hugo/content/articles/009-pulseaudio-under-the-hood.md | 11:36 |
| freemangordon | "Zero-copy mode" | 11:36 |
| uvos__ | freemangordon: yes at account | 11:40 |
| uvos__ | but i can do it | 11:40 |
| freemangordon | please do | 11:40 |
| uvos__ | freemangordon: hmm maybe its pas fault at all | 11:41 |
| freemangordon | wtym? it is PAs fault | 11:41 |
| uvos__ | depends on for what reason shm regions are allocated | 11:41 |
| uvos__ | a misbehaveing client mit be creating the problem by transfering a tonne of small buffers? | 11:42 |
| freemangordon | no matter, on 32bits we have 3GB address space per process | 11:42 |
| freemangordon | no, no, it allocates ^$MB address space, not memory | 11:42 |
| freemangordon | *64MB | 11:42 |
| uvos__ | sure but i think pa mapps client space on thair request | 11:42 |
| freemangordon | does not matter | 11:43 |
| freemangordon | if it is mapped or not, as long as it is allocated | 11:43 |
| uvos__ | ok not sure why not but ok | 11:43 |
| freemangordon | so, for every new client PA allocates 64MB of virtual address space | 11:43 |
| Wizzup | I think the point is that there's a limit to how much more can be allocated virtually | 11:43 |
| freemangordon | yes | 11:43 |
| uvos__ | yeah but dose pa allocate vm space because it wants to or because a client is requesting for it to happen | 11:44 |
| uvos__ | ok | 11:44 |
| freemangordon | and that limit for 32 bit linux is 3GB | 11:44 |
| freemangordon | PA allocates no matter what client does | 11:44 |
| uvos__ | ok | 11:44 |
| freemangordon | it is sevrer setting | 11:44 |
| freemangordon | *server | 11:44 |
| freemangordon | see pa_mempool_new() | 11:44 |
| uvos__ | i gues an application might be creating a tonne of pa connections, ie being lots of clients | 11:44 |
| uvos__ | but other than that ok | 11:44 |
| uvos__ | if its 64MiB per client and its exausting 3GiB space then thats over 40 clients | 11:45 |
| uvos__ | which seams excessive | 11:45 |
| freemangordon | yes, that's what happens it seems | 11:45 |
| freemangordon | we have 45 pools | 11:46 |
| freemangordon | so, more that one connection per client | 11:46 |
| freemangordon | but we have about 20 something clients | 11:46 |
| freemangordon | how is that excessive? | 11:46 |
| uvos__ | 40 clients seams excessive | 11:46 |
| uvos__ | 20 is maybe less so | 11:46 |
| uvos__ | still seams high for the amount of stuff we have running | 11:46 |
| freemangordon | clients are ~20, but they have more than one connection | 11:47 |
| uvos__ | 20 clients that want to play audio? | 11:47 |
| uvos__ | who are these | 11:47 |
| freemangordon | mhm | 11:47 |
| freemangordon | sphone, mafw, xinput-sounds, accounts, notifications, etc,etc | 11:47 |
| freemangordon | do pa-info and you will see them | 11:48 |
| freemangordon | but yes, we have them | 11:48 |
| Wizzup | pacmd | 11:48 |
| Wizzup | list-clients | 11:48 |
| Wizzup | all of the ones I see now are valid ones | 11:48 |
| Wizzup | but yeah like fmg just said | 11:48 |
| freemangordon | still, 20 clients should not lead to resource exhaust | 11:49 |
| Wizzup | in any case we clearly need to allow more clients than 20/40 | 11:49 |
| Wizzup | yeah | 11:49 |
| uvos__ | i only have 11 | 11:49 |
| uvos__ | but ok | 11:49 |
| freemangordon | well, you don;t run leste then | 11:49 |
| Wizzup | systemd-logind also has one open :D | 11:50 |
| Wizzup | two actually | 11:50 |
| freemangordon | mhm | 11:50 |
| freemangordon | and it opens new one for each session IIUC | 11:50 |
| freemangordon | so every ssh session has new PA connection | 11:51 |
| Wizzup | lol | 11:52 |
| Wizzup | well this might be less of an issue eventually with pipewire | 11:53 |
| freemangordon | don;t quote me on that one though | 11:53 |
| Wizzup | so we can decrease shm or disable it I guess | 11:53 |
| freemangordon | decrese | 11:53 |
| freemangordon | so, with 64MB we have 1024 'slots', whatever it is | 11:53 |
| freemangordon | with 8MB segment size we will have 128 slots | 11:54 |
| freemangordon | and that will allow ~380 clients | 11:55 |
| freemangordon | maybe we can do 16MB, dunno, lets see what uvos__ can get from PA devs | 11:55 |
| Wizzup | seems easy enough to try to change client.conf and see | 11:55 |
| freemangordon | there is client.conf.d :) | 11:55 |
| Wizzup | yeah that too, but I mean for us now | 11:56 |
| freemangordon | yeah, I'll make it 16, you can make it 32 | 11:56 |
| Wizzup | no 8? | 11:56 |
| freemangordon | no idea | 11:57 |
| Wizzup | so you want this: | 11:57 |
| Wizzup | shm-size-bytes = 32768 # setting this 0 will use the system-default, usually 64 MiB | 11:57 |
| freemangordon | *bytes* | 11:57 |
| Wizzup | oh | 11:57 |
| Wizzup | 4096 then | 11:57 |
| freemangordon | 32*1024*1024 | 11:57 |
| Wizzup | oh sorry | 11:58 |
| Wizzup | waking up still :) | 11:58 |
| freemangordon | lemme see if it parses MB | 11:58 |
| Wizzup | shm-size-bytes= Sets the shared memory segment size for clients, in bytes. If left unspecified or is set to 0 it will default to some system-specific default, usually 64 MiB. Please note that usually there is no need to change this value, unless you are running an OS kernel that does not do memory overcommit. | 11:58 |
| Wizzup | maybe the last part there is relevant | 11:59 |
| freemangordon | maybe | 12:04 |
| freemangordon | perhaps that our issue | 12:04 |
| freemangordon | lemme check | 12:05 |
| freemangordon | overcommit_memory is 0 | 12:05 |
| freemangordon | https://www.kernel.org/doc/Documentation/vm/overcommit-accounting | 12:05 |
| freemangordon | but, I still think we cannot overcommit more than address space | 12:06 |
| freemangordon | Wizzup: do you know if we have something like PAE on arm? | 12:09 |
| Wizzup | it does exist yes | 12:09 |
| freemangordon | maybe it is disabled in our kernel | 12:10 |
| freemangordon | Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 | 12:10 |
| freemangordon | no lpae here | 12:10 |
| Wizzup | I don't think it works like that on arm | 12:10 |
| Wizzup | maybe | 12:10 |
| Wizzup | https://developer.arm.com/documentation/den0013/d/ARM-Architecture-and-Processors/Architecture-history-and-extensions/Large-Physical-Address-Extension--LPAE- | 12:11 |
| freemangordon | I think it we have to enable huge pages | 12:11 |
| Wizzup | LPAE is optional in the v7-A architecture and is presently supported by the Cortex-A7, Cortex-A12, and Cortex-A15 processors | 12:11 |
| freemangordon | and then we'll ahve more than 4G address space per process | 12:11 |
| uvos__ | if lpae is like x86 pae then no | 12:13 |
| uvos__ | that extends physical address space only, virtual memory space is still 32bit | 12:14 |
| uvos__ | ie you can have more than 4GiB allocated on physical ram, but the mmu can only map 4GiB at a time | 12:15 |
| freemangordon | hmm, yeah, right, address space is still 4GB | 12:15 |
| uvos__ | anyhting else would make no sense anyhow, the abi would have to change to account for bigger pointers | 12:16 |
| freemangordon | yeah, agree | 12:16 |
| freemangordon | ok, I am going to decrease segment size to 16MB, Wizzup to 32MB, if you want you can make yours 8MB | 12:17 |
| freemangordon | to see what will work | 12:17 |
| uvos__ | ok | 12:19 |
| uvos__ | where is the config file exactly? | 12:19 |
| uvos__ | found it | 12:20 |
| uvos__ | ok done | 12:20 |
| freemangordon | /etc/pulse/client.conf.d | 12:20 |
| uvos__ | 8388608 | 12:20 |
| freemangordon | mhm | 12:20 |
| freemangordon | hmm, client.conf.d seems to be ignored | 12:23 |
| Wizzup | freemangordon: I put it in client.conf, but ou want us to start a call then, and then try omp? | 12:24 |
| freemangordon | paplay does the job too | 12:25 |
| freemangordon | cat maps | grep memfd | wc -l | 12:26 |
| freemangordon | in /proc/$pid_of_pa | 12:26 |
| freemangordon | better restart first, so all clients to connect | 12:28 |
| freemangordon | Wizzup: please verify that setting took effect, in /proc/$pa/smaps | 12:35 |
| freemangordon | as here it seems to be ignored | 12:36 |
| freemangordon | Wizzup: no ide why, but that setting is ignore | 13:00 |
| freemangordon | Wizzup: uvos__: the change must be made in daemon.conf, not in client.conf | 13:04 |
| freemangordon | oh, ok | 13:23 |
| freemangordon | *both* daemon.conf and client.conf have to have shm-size-bytes, otherwise one side keeps 64MB | 13:24 |
| Wizzup | ah... | 13:43 |
| Wizzup | will do in a bit! on a call atm | 13:43 |
| Wizzup | freemangordon: btw did you push anything for the headset? or forgot the status | 13:48 |
| KREYREN | sicelo, i kinda need a solution that lets me plug a cable and flash the thing ideally tbh it seems that the maemo-flasher works that way though? | 13:54 |
| freemangordon | Wizzup: no | 14:06 |
| freemangordon | will try to do it after I am back | 14:07 |
| freemangordon | btw, I still ahve issues with reboot/poweroff | 14:07 |
| Wizzup | yeah I do have it now (@reboot) | 14:22 |
| freemangordon | Wizzup: also, it would be good to push some stuff to -stable, if you have time | 14:24 |
| freemangordon | for wure tracker/mafw | 14:24 |
| freemangordon | *sure | 14:24 |
| freemangordon | I can do as well, if you give me the diff script | 14:24 |
| Wizzup | freemangordon: shall we do that a bit later @ devel? | 15:11 |
| Wizzup | maybe when you're back? | 15:11 |
| freemangordon | ok | 15:11 |
| KREYREN | sicelo, for context nixos is heavily focused on reproducibility so ideally i need a way to flash the firmware and the internal storage in one go prior to system boot | 15:12 |
| Wizzup | KREYREN: can you dd to the sd card? | 15:16 |
| Wizzup | or, how does this impact rperoducability? | 15:16 |
| KREYREN | Wizzup, I can, but i want to be able to flash the internal storage as well for e.g. setup where the OS runs there and sdcard is used for swappable things | 15:18 |
| * KREYREN wants to use the device for gaming | 15:18 | |
| KREYREN | The idea is kinda to get a bunch of very cheap sdcards and then place playstation and j2me games on them to swap them like it's nintendo ds with prints alike https://www.datart.cz/pametova-karta-sandisk-micro-sdxc-128gb-uhs-i-u3-v30-pro-nintendo-switch-100r-90w-sdsqxao-128g-gnczn.html tbh | 15:20 |
| Wizzup | you can do this either using an os from the microsd card or if you prepare it correctly, using 0xffff, but I don't know how | 15:21 |
| KREYREN | 0xffff can write to the internal storage? | 15:21 |
| freemangordon | yes | 15:21 |
| KREYREN | oh cool thanks | 15:21 |
| freemangordon | (IIRC) | 15:21 |
| freemangordon | KREYREN: see https://code.tools/man/1/0xFFFF/ , 'supported image types' | 15:24 |
| freemangordon | 'mmc' | 15:24 |
| KREYREN | perfect, i can define a nixos-generator for this | 15:25 |
| freemangordon | but, don't ask me how to create FIASCO image :) | 15:25 |
| KREYREN | is that what pali uboot uses to flash the uboot via 0xffff? | 15:26 |
| freemangordon | I don't think so as it is executed on device | 15:27 |
| freemangordon | and there we have flasher, iirc | 15:27 |
| freemangordon | unfortunately Pali did a rage-quit on everything FOSS a while ago, so we can't ask him :( | 15:28 |
| KREYREN | sad | 15:28 |
| KREYREN | is the uboot unmaintained for the device then? | 15:29 |
| freemangordon | yeah. still, FIASCO image format is well known, but not by me | 15:29 |
| KREYREN | what's fiasco | 15:29 |
| freemangordon | they dropped n900 a while ago | 15:29 |
| freemangordon | "0xFFFF is the Open Free Fiasco Firmware Flasher for Maemo devices. It supports generating and unpacking FIASCO images." | 15:29 |
| freemangordon | https://github.com/pali/0xFFFF | 15:29 |
| KREYREN | oh | 15:30 |
| freemangordon | https://github.com/pali/0xFFFF/blob/master/doc/fiasco | 15:30 |
| KREYREN | i see | 15:30 |
| KREYREN | why did they ragequit | 15:33 |
| Wizzup | disagreements with uboot maintainers | 15:33 |
| KREYREN | i see | 15:34 |
| KREYREN | so the uboot compat for the device is up for grabs? I am currently working on maintaining that for teres-i | 15:35 |
| freemangordon | I think they dropped n900 | 15:36 |
| freemangordon | they = upstream | 15:37 |
| KREYREN | https://github.com/u-boot/u-boot/blob/master/dts/upstream/src/arm/ti/omap/omap3-n900.dts it's still there | 15:37 |
| KREYREN | last week relevant update | 15:37 |
| freemangordon | hmm | 15:37 |
| freemangordon | no idea then | 15:37 |
| freemangordon | but yeah, nothing stops you from asking | 15:37 |
| KREYREN | Hmm seems that the uboot support is implemented and they are merging linux kernel development on top of it | 15:38 |
| KREYREN | https://github.com/u-boot/u-boot/blob/master/dts/upstream/src/arm/ti/omap/omap3-n900.dts#L14-L23 | 15:38 |
| freemangordon | https://github.com/u-boot/u-boot/tree/master/board | 15:38 |
| freemangordon | no nokia/rx51 I can see | 15:39 |
| KREYREN | https://github.com/u-boot/u-boot/tree/master/board/ti/omap3evm ? | 15:40 |
| freemangordon | that's unrelated | 15:41 |
| KREYREN | will look through it | 15:41 |
| freemangordon | see https://github.com/ARM-software/u-boot/tree/master/board/nokia | 15:42 |
| freemangordon | that's not in master | 15:42 |
| KREYREN | i see | 15:43 |
| KREYREN | thanks for info | 15:47 |
| dsc_ | freemangordon: requestLeave() on a channel from conversations for leaving channels | 16:22 |
| dsc_ | how is this picked up on the manager side of things? | 16:22 |
| dsc_ | e.g telepathy-tank | 16:22 |
| dsc_ | do you know? | 16:22 |
| freemangordon | no, sorry | 16:23 |
| dsc_ | https://github.com/TelepathyIM/telepathy-qt/blob/188dece432d090809c5ad88a91cd573c5af61c09/TelepathyQt/channel.cpp#L1841 | 16:24 |
| dsc_ | i dont know what signal to listen for | 16:24 |
| freemangordon | sorry, don;t have time now | 16:25 |
| freemangordon | in a week :) | 16:25 |
| dsc_ | np :) | 16:26 |
| dsc_ | I think I need to install a ChannelInterfaceGroupInterface | 16:26 |
| dsc_ | then listen to MembersChanged | 16:26 |
| dsc_ | will investigatge further | 16:26 |
| Wizzup | freemangordon: with server.conf and client.conf I still have working omp after calls | 16:42 |
| Wizzup | with 32mb | 16:43 |
| arno11 | Wizzup: server.conf ? i guess you mean daemon.conf or ? | 17:15 |
| arno11 | anyway if it works, that's great | 17:16 |
| Wizzup | arno11: daemon.conf and client.conf yes | 17:17 |
| arno11 | ok | 17:21 |
| freemangordon | Wizzup: when it bugs, it is clearly visible in syslog | 17:42 |
| arno11 | Wizzup: sicelo: amazing...i did the shm changes after discovering that i'm able to record sound @8000Hz on N900 now. | 18:35 |
| arno11 | and then calls work both ways @8000Hz now !!! | 18:35 |
| arno11 | (with 2 small changes in cmtspeechdata) | 18:36 |
| arno11 | (previously PA was crashing @8000Hz) | 18:40 |
| arno11 | it even works @16000Hz but sound is distorded | 18:48 |
| dsc_ | arno11: /usr/bin/maemo_kodi_remote exists now | 18:50 |
| dsc_ | (after apt upgrade) | 18:52 |
| arno11 | dsc_: cool will try this night | 18:52 |
| dsc_ | i didnt test on n900 so not sure if it scales well, I did try to account for smaller screens though | 18:53 |
| arno11 | ok | 18:53 |
| arno11 | but @8000hz cpu usage is very high due to xorg burning 40% | 18:59 |
| Wizzup | arno11: shm changes being, decreasing the size? | 19:25 |
| arno11 | yep i just tried 32MB atm | 19:26 |
| arno11 | but really not sure it is directly related | 19:26 |
| arno11 | but i can't explain why PA stopped crashing @8KHz (as you know it was a well known old issue) | 19:37 |
| arno11 | sound is very good btw (as expected) | 19:39 |
| freemangordon | arno11: 32MB might be related with memory_overcommit precent | 19:45 |
| freemangordon | *percent | 19:45 |
| arno11 | ok, btw do you think i should try a lower value ? | 19:47 |
| freemangordon | I am using 16MB on d4 for the last few hours | 19:49 |
| arno11 | ok | 19:49 |
| freemangordon | but, lets run different values for now | 19:49 |
| freemangordon | as we don't know what potential issues that could have | 19:49 |
| arno11 | yep makes sense | 19:49 |
| Wizzup | honestly even 16MB is quite a lot for 44.1khz | 19:56 |
| arno11 | ok | 20:26 |
| arno11 | Wizzup: with 32MB, already a big diff in emulators | 21:06 |
| freemangordon | Wizzup: does this mean that you have an idea how this shared mem is used? | 21:41 |
| Wizzup | I assumed data is put in it and played from pa | 21:43 |
| Wizzup | not sure what else it would be used for for the most part | 21:43 |
| Wizzup | since it still communicates over unix socket | 21:43 |
| arno11 | well, sound through headset is also very good @8KHz now | 22:11 |
| arno11 | let's try dsc's kodi remote now | 22:20 |
| freemangordon | Wizzup: no, they said they communicate over shm | 22:21 |
| Wizzup | arno11: sweet @ better sound | 22:21 |
| Wizzup | freemangordon: it says that unix socket is a requirement to use shm | 22:22 |
| Wizzup | iirc in the link you provided | 22:22 |
| freemangordon | but it is used as a kind of mutex/semaphore/event | 22:22 |
| freemangordon | not for data transfer | 22:22 |
| freemangordon | anyway, I think we can decrease shm size to somethign like 4MiB or somesuch | 22:23 |
| freemangordon | this is still *lots of* data dammit | 22:24 |
| freemangordon | and if we see issues, well, can always increase | 22:24 |
| arno11 | Wizzup: yes :) | 22:28 |
| Wizzup | freemangordon: agree | 22:49 |
| arno11 | dsc_: kodi gui is ok but can't connect to my kodi (both manual and auto) | 22:55 |
| arno11 | *atm | 22:55 |
| arno11 | i'll have a look tomorrow | 22:55 |
| arno11 | rebooting with shm 4MB | 23:02 |
| KREYREN | arno11, hey got the tips? :p | 23:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!