<Wizzup> hm I get no wifi on chimaera image on n900
<Wizzup> oh, something happens now
<Wizzup> I think I need to give it more time :)
<Wizzup> Removing xserver-xorg-legacy (2:1.20.11.2-1+m7) ...
<Wizzup> Killed
<Wizzup> no swap- oof :)
uvos has quit [Ping timeout: 265 seconds]
nela has quit [Ping timeout: 268 seconds]
Danct12 has joined #maemo-leste
nela has joined #maemo-leste
norayr has joined #maemo-leste
nmdv has joined #maemo-leste
moparisthebest has quit [Quit: Gateway shutdown]
nmdv has quit [Ping timeout: 276 seconds]
moparisthebest has joined #maemo-leste
macros_ has quit [Ping timeout: 246 seconds]
macros_ has joined #maemo-leste
joerg has quit [Ping timeout: 276 seconds]
joerg has joined #maemo-leste
Twig has joined #maemo-leste
Twig has quit [Ping timeout: 246 seconds]
ceene has joined #maemo-leste
Twig has joined #maemo-leste
maemish_ has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__> freemangordon: looks good, one small concern i have is that you removed the check for the return value of g_desktop_app_info_launch_uris_as_manager
xmn has quit [Ping timeout: 255 seconds]
<uvos__> this will return false if a .desktop file is availble to handle the sheme, but its exec line points to an application that dose not exist.
<uvos__> err g_app_info_launch_uris_async
xmn has joined #maemo-leste
k1r1t0 has joined #maemo-leste
k1r1t0 has quit [Ping timeout: 255 seconds]
mro has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
uvos has joined #maemo-leste
pere has joined #maemo-leste
<freemangordon> uvos: yes, that was on purpose, because the original code does the same
mro has quit [Remote host closed the connection]
mro has joined #maemo-leste
The_Niz has quit [Ping timeout: 248 seconds]
mro has quit [Remote host closed the connection]
arno11 has joined #maemo-leste
<arno11> Wizzup: i forgot to mention the missing swap on first boot
<arno11> apologies
<Wizzup> arno11: what did you find causes the slowness?
<Wizzup> or did you just solve that with overclocking
<arno11> after two reboots no more slowness
uvos has quit [Ping timeout: 248 seconds]
<arno11> with swap enable and extand root
<arno11> with no overclock it is relatively smooth
<arno11> overclock helps espacially for video decoding
Danct12 has quit [Read error: Connection reset by peer]
<arno11> sdcard under class 10 causes slowness as well especially with aptitude
Danct12 has joined #maemo-leste
<arno11> iirc the slowness after booting is due to automatic apt update every 5 min
<arno11> disabling it helps a lot
<arno11> sorry to forgot all of that
uvos__ has quit [Ping timeout: 260 seconds]
<freemangordon> uvos: also, I changed to use g_app_info_launch_uris_async() which returns void
akossh has joined #maemo-leste
mro has joined #maemo-leste
uvos__ has joined #maemo-leste
<Wizzup> arno11: I see
mro has quit [Quit: Leaving...]
<Wizzup> arno11: interesting that it's so slow the first few times
<arno11> yes weird
<Wizzup> like, after I dd'd it, it was unbearably slow
<Wizzup> like I tried to connect to wifi 5 times but the dialog wouldn't even show
<Wizzup> and I did wait a while
<Wizzup> this could be swap related, potentially
<Wizzup> or rather, the lack of it
<arno11> yes probably
<uvos__> what, are we oom, or close to it on boot on n900 now?
<Wizzup> probably
<uvos__> uff
<Wizzup> I thought we had zswap enabled by default
<arno11> yes close to oom
<uvos__> dosent bode well
<uvos__> we still have a lot of features to implement and any move away from gtk2 will use more ram
<Wizzup> sure
<Wizzup> fremantle also has 750MB of swap
<Wizzup> I doubt it would work without
<arno11> honestly after few tweaks it runs well
pere has quit [Ping timeout: 260 seconds]
xmn has quit [Quit: ZZZzzz…]
<arno11> i have created a simple 1G swap with no zram and it works perfectly
<arno11> even a big ram consuming app like kodi 17 works great
<arno11> be optimistic guys your work on leste is fantastic even on n900
<maemish_> I am following this everyday and I so much appreciate your work. Did not get any answer for my question about getting with new release instructions for getting the swap and for overclocking. The 250/900 setup for overclock worked perfectly on Maemo 5.
<uvos__> there are instructions on overclock on the wiki, and activateing swap is no different than any other linux distro
<uvos__> but it seams we will have a swap partition on sdcard soon anyhow...
<arno11> hi Maemish. yes you could use wiki to overclock 250-800
<arno11> and for swap i will update the wiki asap
xmn has joined #maemo-leste
<freemangordon> uvos__: I still think we shall use emmc dedicated swap
<Wizzup> I think ideally we would have these patches in our kernel
<Wizzup> 12:44 < arno11> be optimistic guys your work on leste is fantastic even on n900
Danct12 has quit [Quit: WeeChat 3.8]
<Wizzup> :)
<freemangordon> :)
<Wizzup> freemangordon: for emmc dedicated swap, if you can share fstab line we can just put it in our images
<freemangordon> arno11: seems you played a bit, do you have any thoughts about whether it is better to use swap on uSD or emmc
<Wizzup> and hope that people didn't reformat their emmc
<freemangordon> it is another partition anyways
<Wizzup> or have one on sdcard by default, and make it easier for people to switch
<uvos__> what patches exactly?
<Wizzup> uvos__: https://leste.maemo.org/Nokia_N900#Overclocking_.2F_Undervolting
<Wizzup> looks like 'just' some dts changes
k1r1t0 has joined #maemo-leste
<freemangordon> arno11: given that rootfs is on uSD too
<freemangordon> Wizzup: I am reluctant to patch the kernel to OC by default
<uvos__> Wizzup: wat? you want to overclock our stock kernel?
<uvos__> no way
<arno11> freemangordon: swap better on usd
<freemangordon> why?
<uvos__> we can provide another dtb to boot sure
<Wizzup> we can provide a package for it in any case
<freemangordon> ok
<Wizzup> uvos__: right, I didn't mean by default per se
<freemangordon> that's better
<Wizzup> but it's better than requiring users to manually modify images
<Wizzup> that will cause trouble later
<freemangordon> uvos__: what about providong dtb that enables OC frequencies, but limit through debugfs by default?
<freemangordon> *providing
<freemangordon> hmm, was it on debugfs
<freemangordon> wherever it is
<freemangordon> arno11: why is better on uSD?
<arno11> freemangordon: better on usd to avoid mistakes on emmc and break everythig from user point of view
<freemangordon> my question was rather from performance POV
<arno11> oh ok
<Wizzup> freemangordon: I think we can just add two lines to /etc/fstab, one with swap on usd, and one with swap on emmc, the emmc one commented
<Wizzup> freemangordon: do you have such a fstab line for me? I will try it now
<freemangordon> we can make smart enough script that enables emmc swap if there is one and create swap loop file or somesuch otherwise
<freemangordon> Wizzup: no, but I can provide one
<freemangordon> I gues
<freemangordon> s
<freemangordon> not now though, sorry
<Wizzup> ok, i'll figure it out
<arno11> sounds good
<Wizzup> swapon /dev/mmcblk1p3
<Wizzup> works in any case
Twig has quit [Ping timeout: 252 seconds]
Twig has joined #maemo-leste
<arno11> Wizzup: freemangordon: maybe a bash script is enough to provide overclock and avoid issue with users
<Wizzup> right, but we would want it to run on kernel upgrades
<freemangordon> umm, why?
<Wizzup> uvos__: is patch for idlest1 included in our kernel?
<freemangordon> it should run on boot
<Wizzup> uvos__: I don't see it
<Wizzup> there was a patch for extra pm info
<freemangordon> Wizzup: so, do we have -testing repo now?
<Wizzup> uvos__: this is 'Allows seeing the deeper idle state blockers in...'
<uvos__> it saturates d4 bus in all modes as tested by "iozone -s 10M -r 512 -i 0 -I -i 1 -i 2 "
<uvos__> maybe run that on n900s emmc
<Wizzup> uvos__: 8ee02090a5bd936bf0feb806fbfb6de5366ac6b8 on maemo-5.15
<uvos__> Wizzup: ok
<freemangordon> I don;t have n900 around to play with, maybe arno11 can do it
<Wizzup> let me see if it applies cleanly
<freemangordon> arno11: can you test emmc on n900 with that uvos__ provided?
<uvos__> what dose this do exactly?
<Wizzup> uvos__: it exposes the blocker bits from omap to userspace
<Wizzup> so we can see what blocks RET, OFF, etc
<freemangordon> gives more info on who blocks idles states
<uvos__> Wizzup: ok, yeah i just read it from the registers
<Wizzup> let me clean up the commit, just a moment
* freemangordon is back to work work
<freemangordon> ttyl
<Wizzup> uvos__: I pushed the commit to branch maemo-idle-report-6.1.y - when you have a chance please look at including it
<uvos__> Wizzup: o
<uvos__> k
pere has joined #maemo-leste
<Wizzup> with this we can use n900-pm scripts to debug blockers
<Wizzup> arno11: I see the power jump constantly from 0.04A to 0.18A with 3.7V with screen off (no way to read it out programatically with this PSU I am afraid), so I guess that gets us to about what you were seeing
<Wizzup> wait, let me turn off htop over ssh :)
<uvos__> lol
<Wizzup> :D
<Wizzup> seems to stay at 0.04A or so, and my serial module always draws a bit of power there
<arno11> cool :)
<arno11> sorry guys i have to go
<Wizzup> ttyl
<arno11> i can help with emmc stuff this evening
<Wizzup> I have swap on emmc already, it's ... fine, I guess
<arno11> if needed
arno11 has left #maemo-leste [#maemo-leste]
<sicelo> Wizzup: that 0.04A is with the blacklist in place?
<Wizzup> yes
<Wizzup> shall I push renewed blacklists (for pm and remove modem) to chimaera-testing ?
<Wizzup> or just to chimaera?
<Wizzup> (for n900)
<uvos__> are we blacklisting something important?
<Wizzup> pm blacklist is omap3_isp / ehci_omap / omap_hdq / hci_nokia / hci_uart
<Wizzup> I am not sure (anymore) what these are used for
<Wizzup> maybe ehci_omap could be relevant for charger detection or something
<uvos__> ehci_omap sounds bad
<uvos__> do we have 1w devices?
<Wizzup> one-wire ?
<uvos__> otherwise load it with the same trick as on d4
<uvos__> that disables bus scanning
<uvos__> omap_hdq is the 1w bus driver
<uvos__> used on d4 to comunicate with the battery
<uvos__> we add a module param there
<uvos__> to make it behave pm wise
<uvos__> the hci stuff probubly breaks bluetooth
<uvos__> so not to great all in all
<Wizzup> right, I don't mind so much breaking bt atm
<Wizzup> we also blacklist it on the d4 after all
<Wizzup> for similar reasons (idle)
<uvos__> no
<uvos__> we backlist it because its broken
<Wizzup> well, that and the loading race
<uvos__> right
<sicelo> the blacklist is safe. none of those modules are critical for anything on n900
<Wizzup> I am not sure if omap hdq is actually used for battery btw
<sicelo> no. it isn't. it's there because omap2plus has bq27xxx-hdq, which N900 doesn't use. our bq27 is on i2c
<Wizzup> check
<uvos__> why dont you look at /sys/bus/w1/
<Wizzup> I guess the isp we know we don't use now, and for ehci_omap, I guess it could impact potentially charger vs pc detection?
<uvos__> to see if anything is useing this bus
<sicelo> Wizzup: no, not that either :-)
<Wizzup> uvos__: will check once I finish the pm test
<sicelo> check what? 1-wire?
<Wizzup> /sys/bus/w1/ doesn't exist on my system now, but I guess that is because I blacklisted the module :)
<uvos__> yes
<uvos__> you have to load it
<uvos__> just load it by hand
akossh has quit [Ping timeout: 264 seconds]
<Wizzup> # find /sys/bus/w1/devices/
<Wizzup> /sys/bus/w1/devices/
<Wizzup> /sys/bus/w1/devices/01-000000000000
<Wizzup> /sys/bus/w1/devices/w1_bus_master1
<Wizzup> # cat /sys/bus/w1/devices/01-000000000000/name
<Wizzup> 01-000000000000
<sicelo> i think i already mentioned a number of times - nothing uses it on N900. it's insufficient?
<Wizzup> sicelo: no, that's fine, I'm just following up on uvos' question
<sicelo> i'm referring to it too
<uvos__> i hardly see the harm looking at the bus to make sure
<sicelo> we're sure already
<uvos__> you are sure
<sicelo> Wizzup: ehci_omap isn't connected with charger detection in any way on N900
<uvos__> anyhow yes apearantly nothing uses it
<Wizzup> I'll make the changes, thanks guys
<uvos__> so ehci_omap, used for host mode i presume?
<sicelo> the blacklist is global or n900-only?
<uvos__> n900 only ofc
<uvos__> otherwise you would be breaking d4 pretty hard
<uvos__> yes i know n900 dosent do otg (ie autoswiching host mode)
elastic_dog has joined #maemo-leste
elastic_dog has quit [Killed (mercury.libera.chat (Nickname regained by services))]
The_Niz has joined #maemo-leste
<Wizzup> rafael2k: did the pkg rename
norayr has left #maemo-leste [Error from remote client]
maemish_ has quit [Quit: Connection closed for inactivity]
uvos__ has quit [Remote host closed the connection]
<Wizzup> I get p=230 or so on n900
Langoor has quit [Quit: No Ping reply in 180 seconds.]
k1r1t0 has quit [Remote host closed the connection]
Langoor has joined #maemo-leste
ceene has quit [Ping timeout: 252 seconds]
maemish_ has joined #maemo-leste
<freemangordon> I think it is better to not blacklist 1w, but instead to the same as on d4
<freemangordon> as we cannot be sure in what state bootloader leaves it
<Wizzup> freemangordon: what do you suggest?
<Wizzup> I don't see the point of not blacklisting a module that isn't even used for anything
<Wizzup> like, not sure why we would complicate it
<freemangordon> because it initializes the HW
<freemangordon> and puts it in a well known state
<freemangordon> in theory ofc
<freemangordon> otherwise we count on the bootloader to init it
<freemangordon> and not, it is not more complex than blacklisting
<freemangordon> *no
gliffy has joined #maemo-leste
maemish_ has quit [Quit: Connection closed for inactivity]
<Wizzup> freemangordon: ok, can you make the leste-config changes then?
<Wizzup> (don't forget gen-displace)
uvos has joined #maemo-leste
rafael2k has joined #maemo-leste
akossh has joined #maemo-leste
<Wizzup> fwiw I won't be around much tonight, back tomorrow
rafael2k has quit [Ping timeout: 264 seconds]
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #maemo-leste
bencoh has quit [Quit: nickerv]
bencoh has joined #maemo-leste
norayr has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: closed]
maemish_ has joined #maemo-leste
<freemangordon> Wizzup: done
<freemangordon> someone shall test on n900 though
<freemangordon> ugh, no iphb module :(
<freemangordon> I wonder why current draw increases drastically when I enable my sip account
gliffy has quit [Quit: Leaving]
<freemangordon> Wizzup: iphb-dkms is installed, but module is not build, I wonder why
Twig has quit [Remote host closed the connection]
maemish_ has quit [Quit: Connection closed for inactivity]