| Wizzup | tk: we'll post a news update (and tweet) when we post our news update (hopefully in a week), at which point I hope that we have a 5.15 kernel for the n900 in a ready to use image | 00:02 |
|---|---|---|
| sixwheeledbeast | tk: https://www.ebay.co.uk/p/1139768844 | 00:03 |
| Wizzup | there's more work to be done in power management, in particular, when the device actually idles properly, there is some oops, which is annoying, so we'll have to fix that | 00:03 |
| tk | sixwheeledbeast: yeah, I found it, thanks :P | 00:03 |
| Wizzup | how we'll fix that, I don't know yet, I'm hoping that tmlind will pull out some magic :-D | 00:03 |
| uvos | Wizzup: "omap4-droid3-xt862.dts deletes ramoops node in motorola-mapphone-common.dtsi" | 00:10 |
| uvos | uh you merged this against mainline right? | 00:11 |
| uvos | pstore for mapphones isent in mainline | 00:11 |
| Wizzup | uvos: oh, I see, well, it's a rfc patch | 00:12 |
| uvos | yeah | 00:12 |
| uvos | just remember that tmlinds -pending branch is not mainline | 00:12 |
| Wizzup | mhm | 00:12 |
| uvos | i have made that mistake once or twice :P | 00:12 |
| Wizzup | btw I forgot to CC you guys on the wifi patch, but I sent that out too | 00:12 |
| Wizzup | our twitter exploded, relatively speaking | 01:43 |
| Wizzup | cool :p | 01:43 |
| lel | MerlijnWajer edited a repository: https://github.com/maemo-leste/sgx-ddk-um | 01:49 |
| ashley | dropping off a quick suggestions regarding the Leste wiki in case if there's interest - I've a MediaWiki 1.35 compatible version of the wiki.maemo.org skin, meant (obviously ;-) for that wiki once I figure out how to migrate it to a supported version of MW (tips, tricks, etc. are all welcome; I know my way around MW but the maemo.org infra scares the hell out of me...); if y'all wanna use it on the Leste wiki for a more consistent-ish look&feel or create | 01:57 |
| ashley | a fork based on it, it's available at https://git.legoktm.com/ashley/mediawiki-skins-Maemo ; installation is as simple as git clone'ing the folder as "Maemo" into the wiki's skins/ folder and adding wfLoadSkin( 'Maemo' ); to the wiki's LocalSettings.php file (which is usually located in the wiki root but maaaaaay be elsewhere depending on how MW was installed? I've no clue how the packaged versions work) | 01:57 |
| ashley | s/suggestions/suggestion/g | 01:58 |
| Wizzup | that would be pretty cool! | 02:00 |
| Wizzup | parazyd mostly manages that infra, I think, but it would be pretty cool to try! | 02:00 |
| ashley | :D awesome! please feel free to poke me about MW-related things, happy to help out :) | 02:01 |
| Wizzup | *nod* | 02:01 |
| Wizzup | one thing to check will be to see how it works with the status thingies we have for the devices | 02:01 |
| Wizzup | in general I think we're looking for someone to give the wiki a bit more love, it feels chaotic to me | 02:01 |
| Wizzup | but that's probably I am chaotic so it's a reflection of some of my contributions | 02:02 |
| Wizzup | :P | 02:02 |
| ashley | heh, it happens ;P but what's insanely cool is that we have cool people like yourself still working on the great mobile OS of all time! I mean, Fremantle was released *quite* a while ago and the Nokia N900 is somewhat ancient in terms of computing devices and especially mobile phones, yet it has outlived - and no doubt will continue to outlive!- many an Android device | 02:04 |
| Wizzup | yup, it's quite fun. :-) | 02:07 |
| * Wizzup zzz | 02:07 | |
| mighty17[m] | <sicelo> "actually i want to do them..." <- Yeah but we'd have to package tmlind's fork, openpvrsgx releases rc kernels only :( | 05:31 |
| sicelo | mighty17[m]: as far as pmos maintainership goes, I'll focus my energies on just mainline kernel (no sgx) | 06:56 |
| mighty17[m] | <sicelo> "mighty17: as far as pmos..." <- so there is probably no need for a "same kernel", we all can just use mainline and add the dts as a patch | 07:01 |
| sicelo | Yes, that's mostly what I meant. What days patch btw? | 07:04 |
| sicelo | s/days/DTS/ | 07:04 |
| mighty17[m] | oh right, n900 already in mainline 😅 | 07:07 |
| sicelo | Haha. How dare you? 😠| 07:09 |
| mighty17[m] | https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/omap3-n900.dts :? | 07:11 |
| sicelo | Yes, it's been there ever since DTS was a thing. And the DTS shows its age by now, e.g. our RGB led definitions fell short of current documentation. Anyway, we're catching up | 07:14 |
| mighty17[m] | yeah so either they go to mainline or we add it as a patch in pmos | 07:17 |
| sicelo | "they" is? :-) | 07:19 |
| mighty17[m] | they as in the updated dts for n90 | 07:20 |
| sicelo | LEDs? fixmaking their way to mainline already. Not much point holding any private patches for anything omap (except sgx, naturally) | 07:20 |
| lel | clort81 closed an issue: https://github.com/maemo-leste/bugtracker/issues/580 (Droid4: USB Charging bounces. (threshold too high?)) | 11:27 |
| Wizzup | looks like the thermal disable might fix the oops in sleep mode, although it looks like there are more issues to resolve when many drivers/modules are loaded | 11:48 |
| lel | MerlijnWajer opened an issue: https://github.com/maemo-leste/bugtracker/issues/590 (Try out this Maemo wiki theme) | 11:50 |
| lel | MerlijnWajer assigned an issue: https://github.com/maemo-leste/bugtracker/issues/590 (Try out this Maemo wiki theme) | 11:50 |
| Wizzup | looks like it is nokia-modem / ssi-protocol that doesn't play well in off mode | 11:56 |
| Wizzup | removing it makes the system (more?) stable | 11:56 |
| Wizzup | in addition to the thermal stuff that is | 11:56 |
| Wizzup | root@devuan-n900:~# sleep 30; /etc/init.d/n900-powermanagement status | 11:57 |
| Wizzup | d=2000-01-01|t=02:02:53|i=OFF:0,RET:271|p=410|c=NA|b=ST_SDRC,ST_OMAPCTRL,ST_I2C1 | 11:57 |
| Wizzup | :-) | 11:57 |
| Wizzup | (booted to recovery mode, with a ton of modules loaded) | 11:57 |
| uvos | Wizzup: neat | 12:08 |
| uvos | Wizzup: i really hope we can make the n900 enter off at some point in the full system even with large entry cost/errata | 12:09 |
| Wizzup | right | 12:11 |
| Wizzup | it doesn't hit RET yet in our full system | 12:12 |
| Wizzup | but we'll get there | 12:12 |
| Wizzup | at least it looks like with Tony's thermal suggestion and ssi_protocol not loaded, it doesn't crash | 12:12 |
| Wizzup | with wlan0 off and modem not loaded I am no longer seeing any blockers though | 12:16 |
| uvos | great | 12:16 |
| uvos | in emergency mode | 12:16 |
| Wizzup | no, system | 12:16 |
| Wizzup | with X and stuff | 12:16 |
| Wizzup | no RET increase though | 12:17 |
| Wizzup | I mean that is with some modules disabled, btw | 12:17 |
| Wizzup | in particular gpio_keys needs work in power saving mode | 12:17 |
| uvos | right i ment in emergency mode the additional timers blocking off in the kernel modules | 12:17 |
| Wizzup | let me clarify | 12:17 |
| Wizzup | RET:271 was in emergency mode, the one you added, with just nokia modem removed | 12:17 |
| uvos | ok and in system mode with some modules unloaded nothings blocking | 12:17 |
| Wizzup | my statement now about wlan off and modem not loaded and not seeing any blockers is with X and h-d etc loaded | 12:17 |
| Wizzup | yes | 12:17 |
| uvos | but the high cost is | 12:17 |
| Wizzup | likely | 12:18 |
| uvos | ok | 12:18 |
| dsc_ | `Tony's Thermal Suggestion` sounds like a hip cocktail bar in the center of town | 12:18 |
| uvos | :D | 12:18 |
| Wizzup | dsc_: we'll stash that with the Microwave Bug | 12:18 |
| Wizzup | omap-dma-engine seems to cause most of the wakeups now it seems | 12:18 |
| Wizzup | I think we'll have to pull out ftrace to make sense of this | 12:18 |
| uvos | that could be any user tho | 12:18 |
| uvos | it has lots | 12:19 |
| Wizzup | yeah | 12:19 |
| Wizzup | uvos: so I think the d3 idles really well, but it's reporting in upower is way off because of the battery stuff | 12:25 |
| Wizzup | I guess that's mostly good news | 12:25 |
| uvos | yeah possible | 12:25 |
| Wizzup | I mean it left it on overnight with wifi on and the capacity looks like it barely decreased :) | 12:26 |
| uvos | maybe it also lacks the unkown power bug d4 has, like bionic | 12:27 |
| Wizzup | mhm | 13:07 |
| tmlind | Wizzup: good to hear it worked, i'm guessing it's the bandgap that needs to be disabled | 13:09 |
| tmlind | Wizzup: there must be some other thermal sensor in use on n900, maybe on one of the pmics if no separate lm75 or similar | 13:10 |
| Wizzup | ok, I'll try that momentarily (bandgap) | 13:11 |
| tmlind | uvos: so is the android power consumption also worse on d4 compared to bionic? | 13:11 |
| tmlind | uvos: maybe the difference relates to the power supply configuration and we need to somehow idle the power supplies on d4? | 13:12 |
| uvos | tmlind: good question | 13:12 |
| uvos | the problem with bionic is atm you cant have android also installed | 13:12 |
| tmlind | oh right | 13:12 |
| uvos | i could fix that | 13:12 |
| uvos | i have to work on clownboot a bit for d3 soon | 13:12 |
| tmlind | ok | 13:13 |
| uvos | tmlind: yeah maybe | 13:13 |
| uvos | tmlind: or its the sensors | 13:13 |
| tmlind | uvos: yeah maybe | 13:13 |
| uvos | tmlind: i have not found the time to test both with no sensors yet | 13:13 |
| tmlind | uvos: me neither.. | 13:13 |
| Wizzup | time, the holy grail | 13:14 |
| uvos | tmlind: dont worry about this (the power problem) ill take it ;) | 13:14 |
| tmlind | uvos: all yours :) | 13:14 |
| Wizzup | uvos: OFF mode on omap4 when? :) | 13:14 |
| uvos | heh | 13:15 |
| uvos | not _that_ problem :P | 13:15 |
| tmlind | Wizzup: i'm guessing your pm bisecting will bring down also d4 idle consumption quite a bit | 13:16 |
| Wizzup | I thought so too, but I don't think it made that much of a difference besides the compact patch | 13:17 |
| Wizzup | tmlind: so if the bandgap works, shall I submit a patch and mark it as 'fixes' for auto enable off mode patch? | 13:36 |
| Wizzup | I'm pretty sure a lot more will not be happy with omap mode enabled by default (ssi_protocol being one of them, gpio_keys another), but we can work on fixing those | 13:36 |
| Wizzup | and we can just carry a revert for now on our tree | 13:36 |
| tmlind | Wizzup: sure yeah that's a fix, but the fix must also explain what is used on n900 for thermal shutdown if bandgap is not in use | 13:36 |
| Wizzup | ok, so some research might be necessary | 13:37 |
| Wizzup | now where do I find a fremantle phone to analyse ... *pulls out phone from pocket* | 13:37 |
| tmlind | yeah sorry looks like i no longer remember what was used on n900, too many devices | 13:38 |
| Wizzup | :) | 13:38 |
| tmlind | Wizzup: looks like there's twl adc <&twl_madc 0> in the dts configured for battery temperature, not sure if that can trigger a thermal shutdown though, maybe there is also something hardware based | 13:46 |
| Wizzup | ok | 13:51 |
| Wizzup | so there is this with all three the nodes from my email disabled: | 13:59 |
| Wizzup | /sys/devices/virtual/thermal/thermal_zone0/temp | 13:59 |
| Wizzup | and there is /sys/devices/platform/68000000.ocp/48072000.i2c/i2c-2/2-0055/power_supply/bq27200-0/temp | 13:59 |
| Wizzup | and the madc | 14:00 |
| Wizzup | # cat /sys/devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:madc/iio:device1/in_temp1_* | 14:00 |
| Wizzup | 56 | 14:00 |
| Wizzup | 14 | 14:00 |
| Wizzup | 28 | 14:00 |
| tmlind | oh ok so does the bq2700 have some temperature shutdown capability? | 14:00 |
| Wizzup | for the record: | 14:00 |
| Wizzup | # cat /sys/devices/platform/68000000.ocp/48072000.i2c/i2c-2/2-0055/power_supply/bq27200-0/temp | 14:00 |
| Wizzup | 239 | 14:01 |
| Wizzup | # cat /sys/devices/virtual/thermal/thermal_zone0/temp | 14:01 |
| Wizzup | 24100 | 14:01 |
| Wizzup | tmlind: I don't know that, is that something in the hw or in the driver/dts? | 14:01 |
| * Wizzup googles | 14:01 | |
| tmlind | Wizzup: it would be in the bq2700 docs with a line wired for shutdown | 14:01 |
| Wizzup | ok | 14:01 |
| Wizzup | Pali or freemangordon might also know | 14:01 |
| tmlind | so what's the fremantle /sys/devices/virtual/thermal/thermal_zone0/temp value? | 14:01 |
| tmlind | maybe that is really using the bandgap sensor with some better code than what the mainline kernel has? | 14:02 |
| Pali | tmlind: Hi! What is the issue? | 14:02 |
| tmlind | Pali | 14:03 |
| tmlind | hi | 14:03 |
| sicelo | Nothing has *thermal* in /sys on Fremantle | 14:04 |
| tmlind | so we want to disable n900 mainline kernel bandgap sensor as it seems buggy on omap3 and needs to be polled for a long time to get any decent values, it ruins the pm | 14:04 |
| Wizzup | fremantle has /sys/devices/platform/omap34xx_temp/temp1_input{._raw} | 14:04 |
| sicelo | And rx51-battery/temp, and bq27200-0/temp too | 14:05 |
| Pali | IIRC fremantle driver omap34xx_temp is what is thermal zone in mainline kernel, and this show temperature reported by omap3 soc | 14:07 |
| Pali | bq27200 temp is what reports bq27200 battery chip | 14:08 |
| Pali | and rx51-battery/temp is temperature reported by battery itself via dedicated (3rd?) pin connected to madc | 14:08 |
| Pali | madc itself reports raw values which are not converted to corrects units; rx51-battery should do it correctly | 14:10 |
| Pali | and about omap34xx_temp, I remember that pavelm was hacking this driver to provide better values... I'm not sure if all patches are in upstream kernel. | 14:11 |
| Wizzup | with /sys/devices/virtual/thermal/thermal_zone0/temp still reporting the correct values, then maybe fremantle does not use bandgap? | 14:12 |
| tmlind | Pali: for omap3 the bandgap driver in mainline pols the registers for quite a while each time to get a sane value :( | 14:13 |
| Pali | there is a long discussion about it: https://lore.kernel.org/lkml/20141226102933.GA28778@amd/ | 14:16 |
| Pali | and this: https://lore.kernel.org/lkml/20141230180002.GC23142@amd/ | 14:17 |
| Pali | "Just be careful when you try to make thermal policy like decisions based on this sensor." | 14:17 |
| Pali | "I guess we won't do that, certainly not anytime soon." | 14:17 |
| tmlind | right, that sounds not reliable | 14:18 |
| tmlind | Wizzup: care to dump out the bandgap register value on fremantle when not reading the temperature? maybe it's configured for thermal shutdown alert only and the value is only read via sysfs if ever? | 14:27 |
| Wizzup | I don't know how to read that register :( | 14:29 |
| tmlind | you can use rwmem or busybox devmem or similar | 14:29 |
| tmlind | the regs to read are: | 14:30 |
| tmlind | 0x48004a08 CM_FCLKEN3_CORE | 14:30 |
| tmlind | this would tell if the bandgap device is clocked at all | 14:30 |
| Pali | beware that kernel has CONFIG_* options for protecting access to /dev/mem which makes access to registers from userspace processes not posible | 14:31 |
| tmlind | uh | 14:31 |
| Pali | but I guess that fremantle kernel is old enough when these CONFIG_* options were not exist or were turned off | 14:31 |
| Pali | when debugging I'm dumping registers from U-Boot, command is: md <addr> 1 | 14:32 |
| tmlind | yeh but that's not the kernel value though.. | 14:32 |
| tmlind | the other register we want to read from fremantle is the bandgap device register that should be 0x48002524 | 14:33 |
| tmlind | yup that's the CONTROL_TEMP_SENSOR register | 14:34 |
| tmlind | maybe somebody can build a custom fremantle kernel with two printks added? :) | 14:34 |
| tmlind | the values at late_initcall time should do | 14:35 |
| Wizzup | I can try later today with rwmem and/or devmem in case it works | 14:39 |
| tmlind | ok | 14:41 |
| tmlind | also, for 4430 i had to change the bandgap to use continuous mode, maybe the same also works for omap34xx and omap36xx.. see commit 735c35352aa6 ("thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430") | 14:42 |
| tmlind | but first we really should check the fremantle configured values for the registers above | 14:48 |
| tmlind | anyways, bbl | 14:50 |
| Wizzup | ttyl | 14:52 |
| uvos | so somethign is wrong with the way we stop glx from working, it breaks sdl2 | 16:22 |
| uvos | so sdl2 tries glx and detects that it works on pvr and advertises opengl and then errors out when it fails | 16:23 |
| uvos | otherwise it would try egl next | 16:24 |
| Wizzup | hm | 16:24 |
| uvos | i can disable opengl | 16:25 |
| uvos | and then it dosent try glx and goes to egl | 16:25 |
| uvos | and everything works (supertux2 with 30 fps :P) | 16:25 |
| uvos | interestingly | 16:26 |
| uvos | supertux2 with gles2 also segfaults on exit with: | 16:27 |
| uvos | PVR:(Error): UCH_CodeHeapDestroy: In heap 0x8f74a0 there are still at least 25 memory leaks [0, ] | 16:27 |
| uvos | PVR:(Error): PVRSRVDestroyDeviceMemContext: allocations still exist in the memory context to be destroyed [0, ] | 16:27 |
| uvos | PVR:(Error): Likely Cause: client drivers not freeing allocations before destroying devmemcontext [0, ]. | 16:27 |
| uvos | PVR:(Error): Couldn't destroy device memory context [0, ] | 16:27 |
| uvos | X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) | 16:27 |
| uvos | Error: signal 11: | 16:27 |
| uvos | corrupted double-linked list | 16:28 |
| uvos | heres a backtrace | 16:28 |
| uvos | #0 0xb4898f38 in XCloseIM () from /usr/lib/arm-linux-gnueabihf/libX11.so.6 | 16:29 |
| uvos | #1 0xb6e6495c in X11_VideoQuit (_this=0x7f5d38) at ./src/video/x11/SDL_x11video.c:451 | 16:29 |
| uvos | #2 0xb6e52a48 in SDL_VideoQuit_REAL () at ./src/video/SDL_video.c:2966 | 16:29 |
| uvos | #3 0xb6e52b46 in SDL_VideoQuit_REAL () at ./src/video/SDL_video.c:2950 | 16:29 |
| uvos | #4 0xb6de82a2 in SDL_QuitSubSystem_REAL (flags=flags@entry=62001) at ./src/SDL.c:370 | 16:29 |
| uvos | #5 0xb6de8432 in SDL_Quit_REAL () at ./src/SDL.c:435 | 16:29 |
| uvos | #6 0xb6830a98 in __run_exit_handlers (status=1, listp=0xb690050c <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108 | 16:29 |
| uvos | #7 0xb6830b5a in __GI_exit (status=<optimized out>) at exit.c:139 | 16:29 |
| uvos | #8 0xb48920ce in _XDefaultError () from /usr/lib/arm-linux-gnueabihf/libX11.so.6 | 16:29 |
| uvos | #9 0xb4892192 in _XError () from /usr/lib/arm-linux-gnueabihf/libX11.so.6 | 16:29 |
| uvos | #10 0xb488ffba in ?? () from /usr/lib/arm-linux-gnueabihf/libX11.so.6 | 16:29 |
| Wizzup | (this might be better suited for a pastebin) | 16:29 |
| uvos | sry | 16:29 |
| uvos | anyhow freemangordon ^^^ ideas on the pvr errors? | 16:29 |
| Wizzup | anything in Xorg.0.log ? | 16:29 |
| uvos | no | 16:30 |
| freemangordon | no, sorry | 16:31 |
| uvos | ok | 16:33 |
| uvos | stx2 can also cause a device hang in about 5 min | 16:49 |
| uvos | interessting | 16:49 |
| uvos | let me try and catch that on serial | 16:49 |
| uvos | unfortionatly i dont get any pstore | 17:13 |
| uvos | and it dosent hang | 17:13 |
| uvos | with serial ret blocked by serial | 17:13 |
| Wizzup | uvos: dmesg -w ? | 17:16 |
| uvos | huh | 17:32 |
| uvos | wierd | 17:32 |
| uvos | http://uvos.xyz/maserati/stx2crash.log | 17:33 |
| uvos | it printed that | 17:33 |
| Wizzup | that seems like after the reset? | 17:42 |
| uvos | yeah | 17:43 |
| uvos | i gues | 17:43 |
| uvos | dosent look like something the mainline kernel would print | 17:43 |
| uvos | ok it just hanged again | 17:43 |
| uvos | and yes this is after reset | 17:43 |
| uvos | looks like its mbmloader or mbm that prints this | 17:44 |
| uvos | anyhow looks like stx2 is very good at making it hang fast | 17:44 |
| uvos | <10 minutes | 17:44 |
| uvos | but im not sure how to get any information from the hang | 17:45 |
| uvos | tmlind: ^^^ ideas> | 17:45 |
| uvos | ? | 17:45 |
| Wizzup | does it happen when droid-pm doesn't run? | 18:00 |
| uvos | no | 18:04 |
| Wizzup | ashley: re: the theme, I am not sure if it makes sense to load from static.maemo.org, should we self-host maybe? | 18:13 |
| uvos | for the reccord, i think the wiki.maemo.org is ugly - not that it really matters what it looks like to me. | 18:14 |
| Wizzup | uvos: we can mod the theme some too | 18:19 |
| Wizzup | I think it is nice to have some custom theme | 18:19 |
| bencoh | +1 | 18:28 |
| uvos | Wizzup: i agree | 18:30 |
| uvos | Wizzup: also ugly is overstating it a bit maybe i think the default looks nicer | 18:31 |
| uvos | Wizzup: maybe it should integrate with the github.io page (or vice versa) | 18:31 |
| tmlind | uvos: yeah that's something from the bootloader, the device should continue booting after that.. but i've noticed enabling pm or modem or sgx in the kernel makes the boot not continue somehow | 18:34 |
| bencoh | Wizzup: congratz (OFF mode on n900) | 18:36 |
| Wizzup | bencoh: there's more work to do tbh, but at least we can hit it in some special cases | 18:38 |
| bencoh | what's missing? | 18:40 |
| bencoh | (kernel-wise) | 18:40 |
| uvos | main problem is that off mode (and ret) on omap3 has a massive entry cost so events have to be really low, there still seam to be kernel events that fire too often | 18:42 |
| uvos | and userspace will probubly also be a problem | 18:42 |
| uvos | the d4 can idle some with 100hz of timers fiering the n900 cant | 18:42 |
| bencoh | what kind of kernel events do we get, apart from external events (proximity / modem) ? | 18:43 |
| uvos | timers | 18:43 |
| bencoh | with blank screen, sgx/touchscreen/lcd should be idling right? | 18:43 |
| uvos | yeah | 18:43 |
| bencoh | timers for what? | 18:43 |
| uvos | we dont know | 18:43 |
| bencoh | ah, alright | 18:44 |
| uvos | the high entry cost on n900 is probubly a blessing is diguise tho | 18:45 |
| uvos | it makes all the little problems that exist and do add up very obvious | 18:46 |
| bencoh | haha, yeah | 18:46 |
| bencoh | well, you could just change the the idle latency to some high value anyway to debug :) | 18:47 |
| uvos | sure | 18:47 |
| bencoh | on another note, https://tuxphones.com/popcorn-computer-pocket-pc-linux-pda-first-look/ seems interesting (no qualcomm inside, and no modem-on-soc I think) | 18:52 |
| Wizzup | https://leste.maemo.org/Main_Page | 19:06 |
| Wizzup | uvos: bencoh: parazyd: ^^^ | 19:06 |
| Wizzup | I see "Tools" twice | 19:06 |
| parazyd | lol | 19:06 |
| parazyd | That feels so weird | 19:06 |
| Wizzup | :D | 19:07 |
| parazyd | Also the links in the toolbar go to maemo.org | 19:07 |
| Wizzup | it's not too bad, but some of the nav would have to change for sure | 19:07 |
| parazyd | Yeah | 19:07 |
| Wizzup | yeah | 19:07 |
| Wizzup | bencoh: re: "what's missing?" (1) ssi-protocol causes almost insta reboot | 19:09 |
| Wizzup | (2) gpio-keys misbehaves | 19:09 |
| uvos | i feal like i cant find anything on that wiki | 19:09 |
| Wizzup | (3) there are some other hangs | 19:09 |
| uvos | despite it being the same :P | 19:09 |
| Wizzup | uvos: yes I feel the same way | 19:09 |
| uvos | funny how you get used to stuff | 19:09 |
| Wizzup | I'm going to revert it again in a bit until we play with it a bit more | 19:09 |
| Wizzup | just leaving it up for folks to see it \ | 19:10 |
| bencoh | Wizzup: insta-reboot? I thought you had 3.5G working? | 19:11 |
| Wizzup | bencoh: yes, but when you enable off mode it goes off the rails | 19:12 |
| Wizzup | bencoh: the modem wasn't working outright on 5.15, I fixed that | 19:12 |
| bencoh | ah | 19:12 |
| bencoh | I see | 19:12 |
| Wizzup | but it still misbehaves in off mode | 19:12 |
| bencoh | (maemo theme on leste wiki feels super weird :D) | 19:12 |
| Wizzup | yeah | 19:12 |
| Wizzup | and there are probably a (lot) more drivers that need idle fixes | 19:12 |
| Wizzup | the one one I looked at and fixed is tsc2005 | 19:12 |
| bencoh | does powertop reports the idle offenders properly? | 19:13 |
| bencoh | -s | 19:13 |
| uvos | not in kerne | 19:13 |
| uvos | l | 19:13 |
| Wizzup | yeah, it's super hard to discern | 19:14 |
| Wizzup | it's all like "delayed_work_timer" | 19:14 |
| bencoh | :( | 19:14 |
| bencoh | ah, I see | 19:14 |
| Wizzup | glad that the timer debugging was removed for security in namespaces! | 19:14 |
| Wizzup | ;-) | 19:14 |
| Wizzup | we'll just need to learn ftrace I guess | 19:14 |
| bencoh | echo 1 > /sys//kernel/debug/tracing/events/timer/enable maybe | 19:14 |
| bencoh | and check /sys//kernel/debug/tracing/trace | 19:14 |
| Wizzup | bencoh: sounds like you'll be helpful with this :P | 19:14 |
| bencoh | haha | 19:14 |
| bencoh | the only n900 I own is my daily driver | 19:15 |
| bencoh | actually I wonder if there is a decent way to check which function a delayed_work runs | 19:16 |
| bencoh | hm, debugfs/tracing gives you the thread name/pid and function, or so it seems | 19:17 |
| bencoh | it might be enough | 19:17 |
| bencoh | (on desktop I get a lot of tick_sched_timer/hrtimer_wakeup, which isn't really helpful) | 19:18 |
| bencoh | kernel is tickless on n900 right? | 19:19 |
| uvos | yes | 19:19 |
| uvos | leste kernel is tickless | 19:19 |
| Wizzup | CONFIG_NO_HZ=y | 19:19 |
| Wizzup | CONFIG_HZ_FIXED=0 | 19:19 |
| Wizzup | CONFIG_HZ_100=y | 19:19 |
| Wizzup | CONFIG_HZ=100 | 19:19 |
| Wizzup | you tell me :) | 19:19 |
| bencoh | haha right, the HZ=100/NO_HZ thing ... well, it means it's as tickless as it can get afaict :) | 19:20 |
| bencoh | (not exactly, there is NO_HZ_FULL as well, but ...) | 19:21 |
| Wizzup | so about the theme | 19:23 |
| Wizzup | I made some minor changes but I think it needs some more work if we want to go for it | 19:23 |
| Wizzup | I think our wiki url rewriting breaks get params :( | 19:25 |
| Wizzup | https://leste.maemo.org/Category:Device&useskin=maemo this should work but it doesn't | 19:25 |
| tmlind | uvos: maybe try your stx2 test with lower sgx frequency | 19:26 |
| Wizzup | anyway, it's available under user preferences | 19:26 |
| bencoh | user preferences allow changing SGX freq? that's ... interesting ... original even :) | 19:32 |
| Wizzup | bencoh: no, skin/theme | 19:32 |
| bencoh | ah | 19:33 |
| bencoh | nevermind :] | 19:33 |
| ashley | Wizzup: re:Maemo.org wiki skin, indeed, that part of the codebase is untested :D because obviously "localhost" is not "maemo.org" and so far I've tested it only on localhost but it works nicely there ;) | 19:58 |
| Wizzup | ashley: I added 'if false' | 19:58 |
| ashley | :D | 19:59 |
| Wizzup | ashley: it's avail as a theme atm on leste.maemo.org | 19:59 |
| Wizzup | if you have an account, log in and go to preferences | 19:59 |
| Wizzup | you can select 'maemo' there | 19:59 |
| ashley | neat, cheers! (I don't, but I'll make one soon ;) | 19:59 |
| Wizzup | I think the double nav bars are not good UX unless we do it everywhere (maemo-leste.github.io, pkgweb, maedevu.maemo.org) | 20:00 |
| Wizzup | but I tried to make it kinda work | 20:00 |
| ashley | (also I'd copy-paste my mandatory "skin != theme != template" rant if I had it readily available, but suffice to say that in a MediaWiki context they all mean different things :P alas, themes are still an extension -- https://www.mediawiki.org/wiki/Extension:Theme -- as there wasn't enough WMF buy-in to have it added to the core MW software...) | 20:00 |
| Wizzup | ah, ok, I should say skin then | 20:00 |
| ashley | *nod* :) mind you, people mix them up all the time and frankly it's quite reasonable because different software has different names for the same thing ("look and feel of the software/website") and the concept of themes in MediaWiki isn't that well-known (despite that the original concept was launched by a commercial wiki hosting company some ~15+ years ago and the extension has been around for like 12-14 years, too!) | 20:06 |
| uvos | tmlind: running it at half the normal rate | 21:41 |
| uvos | seams to have prolonged the time untill it hangs | 21:41 |
| uvos | but not made it not hang | 21:41 |
| uvos | its also very slow | 21:41 |
| Wizzup | uvos__: I think the d4 idles better with the 5.15 with compact disabled, do you see that too? | 22:47 |
| Wizzup | I regularly see '2 days' in status applet now | 22:48 |
| freemangordon | phew, finally sent updated glib patch | 22:48 |
| Wizzup | :) | 22:50 |
| freemangordon | ugh, we'll have to fork desktop-file-utils :( | 23:07 |
| uvos__ | Wizzup: did you rebuild the leste kernel in expieramental without compact? | 23:26 |
| uvos__ | othwise no i havent even tried it | 23:26 |
| Wizzup | uvos__: yes | 23:30 |
| Wizzup | I need to build it again for n900 audio and led, but otherwise it's up to date | 23:30 |
| uvos__ | then i have noticed nothing | 23:30 |
| uvos__ | i have desktop command execution widget display the log of droid4-pm status | 23:31 |
| uvos__ | every 5 minutes | 23:31 |
| uvos__ | and its 100-120 ish as allways | 23:31 |
| Wizzup | ok | 23:36 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!