| freemangordon | arno11: so, you said removing dsmetool call makes pui work? | 06:54 |
|---|---|---|
| freemangordon | arno11: please change /etc/X11/Xsession.post/15hildon-status-menu to: | 07:14 |
| freemangordon | DEBUG_OUTPUT=1 G_MESSAGES_DEBUG=all /usr/sbin/dsmetool -t '/usr/bin/hildon-status-menu > /home/user/hsm.log' | 07:14 |
| freemangordon | then reboot and provide /home/user/hsm.log | 07:14 |
| freemangordon | Wizzup: uvos: seems new kernel fixes "wifi first connect failure" on d4 | 07:19 |
| freemangordon | sicelo: might be related http://47.144.20.137/lists//linux-omap/msg170791.html | 07:22 |
| freemangordon | hmm, bug is still there | 07:30 |
| sicelo | freemangordon: ah thanks. funny enough - i had seen that message, but completely forgot about it when Andreas wrote | 08:28 |
| Wizzup | freemangordon: oh great @ wifi | 11:17 |
| freemangordon | Wizzup: no, it is not fixed | 13:58 |
| Wizzup | ok | 13:59 |
| arno11 | freemangordon: i can't get any logs from hsm xsession during boot. it works only if i block hsm on boot and start it with debug stuff from user space, so not really useful | 16:39 |
| arno11 | (or maybe i'm doing something wrong) | 16:39 |
| arno11 | btw @wifi, i got quite similar bug on my n900 but it happens only without sim iirc | 16:41 |
| arno11 | @hsm, yes pui 'works' without dsmetool but if i click on gps btn for example, hsm stops working | 16:45 |
| Wizzup | freemangordon: btw, re the python porting, the real problem is that there is no way to use gtk2 with python3 | 16:45 |
| Wizzup | so evne if you port say python-hildon, it's mostly useless | 16:46 |
| arno11 | wow, that's a big problem | 16:47 |
| Wizzup | been for years :) | 16:47 |
| Wizzup | uvos: btw did you know https://packages.debian.org/bullseye/gconf-gsettings-backend | 16:48 |
| Wizzup | wonder if that can assist us during the migration | 16:48 |
| uvos | Wizzup: no | 16:57 |
| uvos | Wizzup: yeah that sounds good if it works | 16:57 |
| uvos | one thing i wonder is how this affects the fact that on leste nokia did gconf bakwards | 16:57 |
| uvos | in gconf issues warning when a app reads a key that is not registered with the shema of that app while in gsettings its an error and gsettings will just assert | 16:58 |
| uvos | sadly nokia did this wrong everywhere, mce's gconf keys are for instance in shemas that are packaged with the status applets, which ofc is wrong since mce can run without the status applet but the applet cant run without mce. | 16:59 |
| uvos | same with everything else | 17:00 |
| uvos | so when porting to gesttings you will nessecarly have conflicting shema where you add the gsettings keys to the base dependancy while the applet still has the gconf shema | 17:00 |
| uvos | i wonder what this tool dose in this case | 17:00 |
| Wizzup | mhm, maybe we just need to bite the bullet at some point | 17:07 |
| Wizzup | https://docs.gtk.org/gio/migrating-gconf.html | 17:07 |
| Wizzup | not sure if we do it for bookworm | 17:07 |
| sicelo | I'll submit a patch for droid4-linux in an hour or so (I'm away from PC atm). it solves the issue of getting uevents when charger is connected/disconnected. could we get it built today, at least for experimental, if not devel? | 17:11 |
| sicelo | Wizzup: freemangordon, so now we do get reliable uevents from our charger, yay! it's still not instant, but I think that's correct/normal, per the 2s detection period mentioned in docs. Even the 'standard' LED takes a couple of seconds to show up. Now upower sees the ONLINE state much earlier | 17:19 |
| sicelo | I'll submit the patch upstream as well | 17:21 |
| sicelo | https://github.com/maemo-leste/droid4-linux/pull/12 | 18:30 |
| Wizzup | sicelo: sweet! | 18:45 |
| Wizzup | uvos: if you can prep a build I'll start it | 18:45 |
| Wizzup | freemangordon: for the record from my pov the wifi issue is not juts on boot, it also happens frequently after | 18:49 |
| tmlind | freemangordon: that wifi connect failure on start-up, it might be related to not enough random data during boot as no hardware rng accessible. if so, generating some entropy on boot by reading sensors etc and feeding it to /dev/random might help | 19:01 |
| uvos | i mean the connection failure happens often after also | 19:02 |
| uvos | but only with icd2 never with wpa_cli or networkmanager. Not saying icd is doing anything wrong, just that icd could handle the connection failing better than just giving up. | 19:03 |
| sicelo | maybe someday we shift to iwd :-P | 19:05 |
| uvos | outside the wl1285 driver/firmware maybe having a small bug, association can fail for lots of temporary reasons outside the devices controll, like a burst of interferance, or the ap being busy or whatever | 19:05 |
| sicelo | BTW the connection issue doesn't affect N900? | 19:05 |
| uvos | i have never expiranced it there no? | 19:06 |
| uvos | s/?/. | 19:06 |
| sicelo | someday I might look into improving it icd-side. not making a solemn promise though | 19:08 |
| Wizzup | tmlind: from my pov it looks like the association just fails immediately, three times in dmesg | 19:12 |
| Wizzup | and it fails after milliseconds, not after a sensible set of time | 19:13 |
| Wizzup | uvos/sicelo: it's not a problem in icd2, it's in the driver/kernel | 19:13 |
| arno11 | sicelo: cool ! @charger | 19:15 |
| sicelo | arno11: I'm looking forward to have you test :-) | 19:16 |
| arno11 | np :) | 19:20 |
| tmlind | Wizzup: can you check if wpa_supplicant is actually running at that point? if not enough entropy, i think wpa_supplicant refuses to start | 19:23 |
| Wizzup | I'm confident that it is running, as we first scan on maemo, which uses wpa supplicant, and then connect using the resulting scan list | 19:31 |
| Wizzup | The problem seems to be some race condition between the firmware and the driver I think, it doesn't just happen shortly after boot, but also regularly after that | 19:32 |
| tmlind | ok different issue then | 19:32 |
| tmlind | the issue i'm describing is related to device not connecting to wlan automatically after boot if not enough entropy | 19:33 |
| Wizzup | check | 19:33 |
| Wizzup | what I mean is this: | 19:33 |
| Wizzup | [17366.187713] wlan0: authenticate with 7c:77:16:35:f5:c1 | 19:33 |
| Wizzup | [17366.198211] wlan0: send auth to 7c:77:16:35:f5:c1 (try 1/3) | 19:33 |
| Wizzup | [17366.210052] wlan0: send auth to 7c:77:16:35:f5:c1 (try 2/3) | 19:33 |
| Wizzup | [17366.220886] wlan0: send auth to 7c:77:16:35:f5:c1 (try 3/3) | 19:33 |
| Wizzup | [17366.231414] wlan0: authentication with 7c:77:16:35:f5:c1 timed out | 19:33 |
| Wizzup | see hoe quickly the auth times out - within 40ms of starting the authentication, and that's three attempts even | 19:34 |
| Wizzup | how quickly* | 19:34 |
| tmlind | hmm ok | 19:34 |
| Wizzup | here is a working one 15 seconds later: | 19:34 |
| Wizzup | [17384.560638] wlan0: authenticate with 7c:77:16:35:f5:c1 | 19:34 |
| Wizzup | [17384.575073] wlan0: send auth to 7c:77:16:35:f5:c1 (try 1/3) | 19:34 |
| Wizzup | [17384.580078] wlan0: authenticated | 19:34 |
| Wizzup | [17384.590179] wlan0: associate with 7c:77:16:35:f5:c1 (try 1/3) | 19:34 |
| Wizzup | [17384.598358] wlan0: RX AssocResp from 7c:77:16:35:f5:c1 (capab=0x1c11 status=0 aid=3) | 19:34 |
| Wizzup | [17384.611450] wlcore: Association completed. | 19:34 |
| tmlind | maybe run wpa_supplicant in the foreground to log it? | 19:35 |
| tmlind | in the verbose mode | 19:35 |
| Wizzup | can do, from what I recall it doesn't get anything meaninful, but that was maybe 2 years ago at this point | 19:36 |
| tmlind | ok | 19:37 |
| Wizzup | I remember trying to figure out if wpa supplicant want setting some bad timeout, but it didn't seem that was the case, I might even have logs somewhere from trying more verbose debug on the kernel wifi layer... | 19:37 |
| tmlind | i guess the kernel could run out of entropy during runtime too, should see something in the dmesg | 19:38 |
| Wizzup | I think I remember toying with wl12xx_debug_level, let me check irc logs | 19:43 |
| tmlind | and you do have separate wl12xx mac addresses for each device set with the tool from uvos? | 19:46 |
| tmlind | duplicate mac addresses could cause issues like you're describing.. | 19:46 |
| sicelo | I also see those issues, and have exactly one D4 ;-) | 19:48 |
| tmlind | ok | 19:49 |
| Wizzup | yeah it happens on all the mapphones I think | 19:52 |
| Wizzup | maybe it's related to a force country code, like with iw get reg | 19:54 |
| Wizzup | but I don't think so | 19:54 |
| Wizzup | freemangordon: I think we can close https://github.com/maemo-leste/bugtracker/issues/746 and https://github.com/maemo-leste/bugtracker/issues/747 ? | 20:25 |
| tmlind | now that i think about it, it was my mz617 where wl12xx did not often connect on boot while my d4 was connecting | 20:36 |
| Wizzup | if it didn't connect on boot, might be worth checking if you see the same early auth aborts in dmesg | 20:36 |
| tmlind | here's the openrc script i did to add more entropy before wpa_supplicant, might be worth a try just in case: http://muru.com/linux/mapphone-entropy | 20:37 |
| tmlind | might be a good idea to add something like that anyways for devices with no hw rng available | 20:37 |
| Wizzup | perhaps haveged can also help | 20:37 |
| Wizzup | heh iio seems clever too :) | 20:37 |
| tmlind | not sure if the sha256sum makes any difference there | 20:38 |
| tmlind | anyways, that made my mz617 to connect on boot | 20:38 |
| uvos | oh i thought the kernel uses sensors for rng anyhow - like it dose input devices | 20:39 |
| tmlind | yeah but nothing reads them on boot | 20:39 |
| uvos | i see | 20:40 |
| uvos | i gues i expected the kernel to just read them if it finds itself out of entropy | 20:40 |
| uvos | so til | 20:40 |
| tmlind | uvos: actually looks like iio devices need to add it? see git grep add_device_randomness drivers/iio/ | 20:41 |
| tmlind | i guess we could also automatically read some data on the iio driver probe | 20:42 |
| tmlind | but nothing would still ensure iio would be loaded before wl12xx.. | 20:43 |
| tmlind | hmm not sure if the iio driver should call add_device_randomness() on a single sensor data, it may not change at all while a combination of many sensors is likely to change | 20:48 |
| freemangordon | arno11: don't follow, did you made the change I asked for? | 20:53 |
| freemangordon | this: | 20:53 |
| freemangordon | DEBUG_OUTPUT=1 G_MESSAGES_DEBUG=all /usr/sbin/dsmetool -t '/usr/bin/hildon-status-menu > /home/user/hsm.log' | 20:53 |
| arno11 | freemangordon: yes, with your changes | 20:54 |
| arno11 | yes | 20:54 |
| freemangordon | it outputs to /home/user/hsm.log | 20:54 |
| freemangordon | not to xsession-error | 20:54 |
| arno11 | yes but the file is empty | 20:54 |
| freemangordon | how's that?!? | 20:55 |
| arno11 | *empty whatever i do | 20:55 |
| arno11 | it creates only an empty file | 20:55 |
| arno11 | it works only from userspace | 20:55 |
| freemangordon | I tested in the VM and can assure you the file is not empty | 20:55 |
| freemangordon | sorry, what is userspace? | 20:55 |
| arno11 | i mean, after boot | 20:56 |
| freemangordon | please elaborate, what works after boot? | 20:56 |
| freemangordon | arno, hmm, perhaps try to append | 20:57 |
| freemangordon | DEBUG_OUTPUT=1 G_MESSAGES_DEBUG=all /usr/sbin/dsmetool -t '/usr/bin/hildon-status-menu >> /home/user/hsm.log' | 20:57 |
| arno11 | to resume, as i previously said: only an empty file with your changes. if i block hsm on boot and start it with debug stuff after boot, it works | 20:57 |
| arno11 | i already tried | 20:57 |
| arno11 | same result | 20:58 |
| freemangordon | did you try with a different file name? | 20:58 |
| arno11 | yep | 20:58 |
| freemangordon | maybe you have some remnant from previous tries that overwrite hsm.log | 20:58 |
| arno11 | i already check | 20:58 |
| freemangordon | see, with DEBUG_OUTPUT=1, h-s-m writes to console | 20:59 |
| freemangordon | there is no way for that to not work if written properly | 20:59 |
| arno11 | agree | 21:00 |
| freemangordon | so, please pastebin the content of /etc/X11/Xsession.post/15hildon-status-menu | 21:00 |
| arno11 | if you want | 21:01 |
| arno11 | https://paste.debian.net/1331448/ | 21:03 |
| freemangordon | :( | 21:05 |
| freemangordon | arno11: where are the quotes? | 21:05 |
| freemangordon | DEBUG_OUTPUT=1 G_MESSAGES_DEBUG=all /usr/sbin/dsmetool -t '/usr/bin/hildon-status-menu >> /home/user/hsm.log' | 21:06 |
| freemangordon | see the apostrophes around the command | 21:06 |
| freemangordon | see mine https://pastebin.com/gHrLYPff | 21:07 |
| arno11 | omg, tired today, sorry | 21:07 |
| arno11 | will check again | 21:07 |
| freemangordon | ok | 21:08 |
| arno11 | biab, rebooting | 21:10 |
| freemangordon | tmlind: basically every second connection attempt fails | 21:18 |
| freemangordon | sicelo: why it started to work? | 21:19 |
| freemangordon | like, you said it sends wring status | 21:19 |
| freemangordon | *wrong | 21:19 |
| Wizzup | ftr I'm working on daedalus a bit | 21:20 |
| Wizzup | looks like gtk2 is completely unchanged from bullseye->bookworm | 21:20 |
| Wizzup | kinda nice in some way ;) | 21:20 |
| freemangordon | yeah, saw it on ##leste-ci | 21:20 |
| freemangordon | I hope that finally we'll have fixed sgx userspace blobs | 21:21 |
| Wizzup | oh yes, that will be interesting for sure | 21:22 |
| freemangordon | do you remember where the new repo is? | 21:22 |
| Wizzup | https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/log/ ? | 21:22 |
| Wizzup | that's just in my firefox history | 21:22 |
| Wizzup | don't know if it is new | 21:22 |
| freemangordon | I meant - the new mesa | 21:23 |
| Wizzup | I don' | 21:23 |
| Wizzup | t understand what you mean | 21:23 |
| freemangordon | there is a mesa fork that imcludes support for pvr | 21:23 |
| freemangordon | *includes | 21:24 |
| Wizzup | sorry, don't remember | 21:24 |
| Wizzup | https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/log/?h=1.17.4948957/mesa/glibc-2.35 this has mesa in the tag at least | 21:24 |
| Wizzup | https://docs.mesa3d.org/drivers/powervr.html ? | 21:26 |
| Wizzup | this is only for new powervr I think | 21:27 |
| freemangordon | wait | 21:27 |
| Wizzup | mhm | 21:28 |
| freemangordon | see https://gitlab.freedesktop.org/StaticRocket/mesa/-/branches/stale | 21:28 |
| freemangordon | https://gitlab.freedesktop.org/StaticRocket/mesa/-/commits/powervr/kirkstone/22.3.5/?ref_type=heads | 21:29 |
| Wizzup | and this is for old powervr hw? | 21:30 |
| freemangordon | yes | 21:31 |
| freemangordon | this is the same/similar to what we have | 21:31 |
| freemangordon | but for newer mesa that dropped old drivers support | 21:31 |
| uvos | dose that even matter given that mesa-amber exits (in debian too) | 21:32 |
| freemangordon | no idea | 21:33 |
| uvos | mesa-amber is a maintianed fork with the support for mesa classic drivers | 21:33 |
| freemangordon | but I guess yes, it matters as we can ask for help/support/fixes | 21:33 |
| uvos | it was forket at the same time as we forked mesa for pvr | 21:33 |
| uvos | so we just rebase on that and its the same thing | 21:33 |
| uvos | freemangordon: i gues yes | 21:33 |
| Wizzup | there is also this https://gitlab.freedesktop.org/StaticRocket/mesa/-/commits/powervr/23.2.1 | 21:37 |
| freemangordon | uvos: https://gitlab.freedesktop.org/StaticRocket/mesa/-/tree/powervr/kirkstone/22.3.5/src/gallium/frontends/sgx?ref_type=heads | 21:37 |
| freemangordon | Wizzup: I don;t think 23.2.1 branch supports sgx | 21:38 |
| Wizzup | ok | 21:40 |
| Wizzup | well bullseye had 20.x, we had 21.x ourselves, and bookworm has 22.x, so I guess we can make this work | 21:40 |
| freemangordon | mhm | 21:41 |
| freemangordon | I will forward-port whatever patches we have on top | 21:41 |
| freemangordon | I really hope that would finally fix qt fullscreen hangs | 21:42 |
| Wizzup | https://github.com/maemo-leste/bugtracker/issues/751 | 21:42 |
| Wizzup | there is some time until we hit mesa ;) | 21:42 |
| freemangordon | yeah | 21:42 |
| freemangordon | hildon-desktop-clutter-1.x? | 21:42 |
| freemangordon | do we need that? | 21:42 |
| freemangordon | ok, have to go, night! | 21:44 |
| Wizzup | we do not need it | 21:45 |
| Wizzup | gn | 21:45 |
| Guest2030 | freemangordon: https://paste.debian.net/1331458 | 21:47 |
| arno11 | Wizzup: not sure issues 746 and 747 should be closed: on n900 pulsesrc works but with few changes iirc and outgoing still doesn't work | 21:51 |
| Wizzup | ah | 21:57 |
| arno11 | Wizzup: outgoing works on another network on my device :) | 22:14 |
| arno11 | too happy | 22:15 |
| Wizzup | I still have to do more testing of this and also experience that feeling :D | 22:15 |
| arno11 | ok :) | 22:15 |
| Wizzup | freemangordon: ah, so the building of packages with the same version went wrong because the dch hook didn't have aliases for chimaera and daedalus, only for ascii and beowulf | 22:24 |
| Wizzup | oops | 22:24 |
| Wizzup | (I fixed it now obviously) | 22:47 |
| uvos | Wizzup: whats the use of mz617-tiny-bootstrap supposed to be? | 23:03 |
| Wizzup | that's the image that you can flash to install leste to the main partition | 23:09 |
| Wizzup | but in its current form you can't just flash it | 23:09 |
| uvos | yeah but its not fit for puropse | 23:09 |
| uvos | unless i missunderstand | 23:09 |
| Wizzup | not yet, no | 23:09 |
| uvos | the only partition flashable via fastboot that is large enough is cache at 850 ish mb | 23:09 |
| uvos | but this image's fs is 3Gigs in size and its 2 partitons | 23:10 |
| uvos | Wizzup: ok gotcha | 23:10 |
| Wizzup | well yes but the 3GB aren't all used | 23:10 |
| Wizzup | it's close to what it is supposed to be, but it's not it...yet | 23:10 |
| uvos | sure but i was expecting this to be an image that can be "fastboot flash cache image.img " | 23:10 |
| Wizzup | yeah. | 23:10 |
| Wizzup | maybe you can try massaging it for this purpose | 23:11 |
| Wizzup | I think it just needs a small amount of losetup (loopback) massaging | 23:11 |
| uvos | i hosed my mz617 again :P | 23:11 |
| Wizzup | uf :D | 23:11 |
| Wizzup | do you still have my manually made img? | 23:11 |
| uvos | im manually makeing an img from the tiny image | 23:11 |
| Wizzup | ok, pls record the steps | 23:11 |
| uvos | its not hard just create a 850mb fs and copy both boot and root there | 23:11 |
| Wizzup | yeah that works too | 23:12 |
| uvos | im not shure how the image builder works at all | 23:12 |
| uvos | but i think this should be fairly trivial to do or? | 23:12 |
| Wizzup | mostly yes | 23:13 |
| Wizzup | https://github.com/maemo-leste/image-builder/blob/master/chimaera.config | 23:13 |
| Wizzup | https://github.com/maemo-leste/image-builder/blob/master/chimaera.config | 23:13 |
| uvos | should the second one be a different link? | 23:13 |
| Wizzup | yeah meant to link to the .blend file as well | 23:13 |
| Wizzup | in any case the .config line 167 is where most of the cleaning happens, and then I guess it needs a special finalize procedure | 23:14 |
| Wizzup | sorry I menat .blend 167 | 23:14 |
| Wizzup | github is just silly | 23:14 |
| uvos | i must be blind | 23:17 |
| uvos | but i dont see where the partition table and the partitions are created | 23:17 |
| uvos | thats the main problem really the mz617 image needs to be one parition not 2 | 23:17 |
| uvos | same for installing to mapphone emmc in gernal (having emmc images for d4 would be a nice spinoff here) | 23:18 |
| Wizzup | you're not blind, it's just not that easy to plug in :) | 23:20 |
| Wizzup | let me see if I can find it | 23:20 |
| Wizzup | I think arm-sdk/boards/mz617.sh would need to be modified | 23:21 |
| Wizzup | and then I don't know if arm-sdk supports a single partition for everything, probably does | 23:21 |
| Wizzup | it looks like if bootfs is none (do not know if that is a special zsh value or not) then it will not do any bootfs stuff | 23:23 |
| Wizzup | this is in arm-sdk/libdevuansdk/zlibs/imaging | 23:23 |
| uvos | oh no | 23:28 |
| uvos | https://uvos.xyz/maserati/xycrash.txt | 23:28 |
| uvos | the stock kernel crashes before it even gets to kexec | 23:28 |
| Wizzup | strange... | 23:29 |
| Wizzup | seems like it is unhappy with some of the partitions | 23:30 |
| Wizzup | maybe if you clear data.. (but yeah) | 23:30 |
| Wizzup | actually wai | 23:30 |
| Wizzup | it doesn't crash before kexec | 23:30 |
| Wizzup | insmod: can't insert '/lib/modules/3.0.8-g448a95f/kernel//uart.ko': File exists | 23:30 |
| Wizzup | insmod: can't insert '/lib/modules/3.0.8-g448a95f/kernel//arm_kexec.ko': File exists | 23:31 |
| Wizzup | insmod: can't insert '/lib/modules/3.0.8-g448a95f/kernel//kexec.ko': File exists | 23:31 |
| uvos | thats fine | 23:31 |
| Wizzup | kexec failed: Operation not permitted | 23:31 |
| uvos | thats huh | 23:31 |
| uvos | yeah | 23:31 |
| Wizzup | isn't that when it should kexec? | 23:31 |
| uvos | yeah | 23:31 |
| uvos | wonder why it then dereferenes a nullptr | 23:31 |
| Wizzup | probably something with system or data being mangled from its pov | 23:31 |
| uvos | ok well one problem is | 23:34 |
| uvos | that the image lacks omap4-xyboard-mz617.dtb | 23:34 |
| uvos | :P | 23:34 |
| Wizzup | heh. | 23:38 |
| Wizzup | thx for trying this, I think we can maybe get this fixed pretty soon | 23:38 |
| uvos | Wizzup: yeah so the current devel pacakas the dtb | 23:40 |
| uvos | but the images all lack it | 23:40 |
| uvos | i presume thats because the stable kernel also lacks | 23:40 |
| Wizzup | hm, I think it's because I haven't built images in 2-3 weeks | 23:41 |
| Wizzup | but yes, at the time of building that image it probably lacked it | 23:41 |
| Wizzup | (I have to restart the image builder vm) | 23:41 |
| Wizzup | brb | 23:41 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!