maemish_ has quit [Quit: Connection closed for inactivity]
k1r1t0 has quit [Ping timeout: 260 seconds]
sunshavi_ has quit [Ping timeout: 248 seconds]
noidea_ has quit [Ping timeout: 260 seconds]
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
k1r1t0 has joined #maemo-leste
Twig has joined #maemo-leste
ceene has joined #maemo-leste
maemish_ has joined #maemo-leste
<maemish_> Epiphany browser starts quickly but after it opens and you see the page it crashes.
<maemish_> This is seen in xterm after that
<freemangordon> get a backtrace
rafael2k has joined #maemo-leste
rafael2k has quit [Quit: Leaving]
rafael2k has joined #maemo-leste
Twig has quit [Remote host closed the connection]
rafael2k_ has joined #maemo-leste
xmn has quit [Ping timeout: 252 seconds]
rafael2k has quit [Ping timeout: 255 seconds]
rafael2k_ is now known as rafael2k
<Wizzup> freemangordon: could easily be out of ram, too
<Wizzup> trying to browse the modern web on a n900 is like using a 2004-2005 celeron (which is actually way more powerful) to try and browse the modern web
<Wizzup> maybe some super simple thing like dillo can work, but it won't support all the new stuff
<sicelo> yeah. realistically, people should mostly just stop using/obtaining N900 if browsing is a main requirement. there's not a lot that we can do about the web getting bloated, and that trend won't stop
Danct12 has joined #maemo-leste
nohit has quit [Ping timeout: 255 seconds]
nohit has joined #maemo-leste
Danct12 has quit [Remote host closed the connection]
<n900> but still awesome as an irc client! :)
<Wizzup> :p
uvos__ has joined #maemo-leste
<uvos__> Wizzup: ping
<uvos__> maemish_: sicelo: yeah even the mapphones are pushing it when used to browse modern webpages
<uvos__> im suprised qtwebrowser manages to dsiplay any page of any complexity on n900
<uvos__> ff just ooms immidatly so its better than that :)
<freemangordon> right
<maemish_> But Maemo 5 with Opera Mobile, Fennec or Micro-b with nginx loads just fine without problems. So it is not just the question of bloated web.
<freemangordon> maemish_: right, but none of the 'modern' browsers is optimized for 256 MB of ram
<freemangordon> also, which exactly page microb or opera have no issue loading? besides tmo that is
<freemangordon> also, do you have swap enabled? also, make sure to disable ramzswap
<maemish_> I have been using Opera just fine for browsing. Or Fennec. And Micro-b with nginx works suprisingly well.
<freemangordon> for some reason it is enabled on n900 making things even worse
<freemangordon> ok, but lets have one site that loads ok in fremantle and use it as a benchmark
<freemangordon> "fine for browsing" is too general
<maemish_> I have not done any tweaks for swap. Thought there is swap by default.
<freemangordon> nope, iirc
<freemangordon> besides ramzswap and that shall be disabled
<freemangordon> so make sure to disable ramzswap and enable emmc swap
<freemangordon> and try again
<freemangordon> but don;t expect miracles, FF is FUBAR after v78
<maemish_> Is there any info how to? Like to an idiot level?
<freemangordon> give me the output of "swapon -s"
<maemish_> Not having device at hand. At work. Will do in the evening. Thanks for bothering to help.
<freemangordon> ok, I will be a bit busy in the evening, but in general you need swapon/swapoff commands
<freemangordon> and you have to identify emmc swap partition
<freemangordon> (s)fdisk -l
<maemish_> Have been active on the forum helping others without using N900 for a year. Lot to remember.
<maemish_> Your info made this idiot to say "Huh?"
<freemangordon> hmm?
<freemangordon> why is that
<maemish_> But thanks. Gonna see if I can with that info and with help from my friend go forward. It is no problem.
<freemangordon> I mean - maybe ask google how to list enabled swap etc
<freemangordon> ok
<maemish_> Thanks.
<sixwheeledbeast> `blkid -t TYPE=swap` ?
* freemangordon just learned something new :)
<sixwheeledbeast> so performance is better if swap is on the device?
<freemangordon> for leste, yes
<sixwheeledbeast> ah
<freemangordon> like for fremantle swap has to be on uSD ;)
<sixwheeledbeast> that's why i wondered.
<freemangordon> sixwheeledbeast: on fremantle /opt is on emmc
<uvos__> idk if thats true
<freemangordon> uvos__: what is "thats"?
<uvos__> for d4 a modern sdcard is mutch faster with random writes
<uvos__> than its emmc
<freemangordon> not for n900
<uvos__> and seqential is mutch faster too
<uvos__> if you enable 100mhz hack
<freemangordon> we talk n900 here
<uvos__> n900 can do this hack too
<freemangordon> but, swap on emc means 2 io channels
<uvos__> freemangordon: i would not be so sure, i have a sdcard that can saturate the bus at 50Mhz with random writes
<freemangordon> one for root and another for swap
<uvos__> ie 25MB/s
<freemangordon> on n900 emmc does more than 15MB/s
<freemangordon> iirc
<uvos__> well thats al lot slower than a good application class sdcard
<Wizzup> uvos__: pong
<freemangordon> combined with separate channel gives better performance in general
<freemangordon> swap io should not wait for rottfs io
<uvos__> freemangordon: sure maybe, but its not that clear cut as you make it out to be
<freemangordon> *rootfs
<freemangordon> also, you talk about some hacks and special cards
<uvos__> freemangordon: no hacks
<uvos__> freemangordon: for faster random
<uvos__> but yes you need a "special" ie modern application class sdcard
<freemangordon> uSD on n900 is 2 lines, IIRC
<freemangordon> emmc is 4
<uvos__> right
<uvos__> but this dosent matter if emmc cant saturate its bus
<freemangordon> sure
<freemangordon> but emmc on n900 is *very* fast
<uvos__> Wizzup: just wonderning what you wanted
<uvos__> freemangordon: 15 years ago, sure
<freemangordon> can;t remember the benchmarks from back then
<maemish_> You guys can't even believe how lucky I feel to follow this conversation.
<Wizzup> uvos__: just a sec
<maemish_> Peak behind the scenes to esoteric info.
<freemangordon> uvos__: unfortunately google does not give any results for n900 emmc benchmark
<uvos__> freemangordon: ok well we should disable zswap and add a script that asks the user where to place swap maybe
<freemangordon> but I can assure you that copy over usb mass storage is done with 16MB/s
<freemangordon> right
<freemangordon> zswap on n900 is very bad idea
<uvos__> thats ~seqential then and really slow,
<bencoh> 16MB/s is very decent for a 2009 device
<uvos__> compeared to a modern sdcard
<freemangordon> not really sequential
<sixwheeledbeast> someone on tmo claimed 13000Kb/s using flasher3.5 output ?
<uvos__> shoudl be fairly seqentuail, depending on allocations on the card ofc
<bencoh> I'd say it counts as sequential as well yeah
<freemangordon> sixwheeledbeast: this is not good benchmark
<freemangordon> because we have USB playing there
<sixwheeledbeast> fair enough
<freemangordon> sixwheeledbeast: I remember running benchmarks locally on the device back then
<freemangordon> but neither can remember nor I can find the results :)
<freemangordon> uvos__: still, my gut feeling tells me that a separate io channel for swap will be better than even the fastest uSD card, as it is not only the raw speed thet matters
<sixwheeledbeast> i'd like to stick to my cycling swap defragging method if required, so just interested in performance for leste having all on the card.
<freemangordon> maybe provide so benchmarks if possible
<freemangordon> *some
<sixwheeledbeast> it does make sense bandwidth wise i agree
<uvos__> freemangordon: that might be true, is deffinatly true when the sdcard is otherwise loaded, but idk how this presents itself in regular usage
<freemangordon> IIRC omap3 runs its mmc bus on max 54MHz, right?
<uvos__> something to play around with
<uvos__> freemangordon: yes, scard spec requires 1.8v trancievers if you want to do more
<uvos__> which we dont have
<uvos__> *sdcard
<freemangordon> so, theoretical bus bandwith for uSD is 54/4 = 13.5 MB/s, no?
<uvos__> bus with should be 4 and 8 not 2 and 4
<uvos__> iirc, def true for d4
<freemangordon> umm, have to check it, but I think on n900 it is 2 and 4
<uvos__> i thin 2 isent valid for sdhc
<freemangordon> does anyone have n900 boot dmesg log around?
<freemangordon> kernel tells us the bus width
<freemangordon> "mmc1: switch to bus width 1 failed"
<bencoh> maybe, lemme check
<bencoh> hmm, nope, sorry. are you looking for fremantle or leste btw?
<freemangordon> well, we are looking for upstream kernel :)
<bencoh> ah, nevermind then
<freemangordon> joerg: do you remember uSD vs eMMC bus widhts on n900?
<freemangordon> uvos__: right, according to schematic we have MMC_DATA0 to MMC_DATA3 for MMC1 and MMC_DATA0 to MMC_DATA7 for MMC2
<freemangordon> so uSD is 4 bits
<bencoh> mmc1 has 4, mmc2 has 8
<freemangordon> :nod:
<bencoh> looks like we're looking at the same pdf :]
<freemangordon> joerg: nevermind
<freemangordon> bencoh: yeah
<freemangordon> uvos__: so, max theoretical transfer is 27MB/s
<uvos__> freemangordon: right so any modern uhs sdcard can massivley outperform emmc
<uvos__> seqentally
<uvos__> and A class ones with do mutch faster random
<freemangordon> I am still not convinced, because those 16MB/s are over USB
<freemangordon> if we bench eMMC on the device, I will not be surprised if we see like 25MB/s
<freemangordon> maybe I can do that soon
<freemangordon> remember back then in HDD times? all the recommendations were to have swap on a separate HDD (and on a separate IDE channel), even if that HDD is slower than rootfs one?
<uvos__> sure
<freemangordon> the same here
<uvos__> but on d4 emmc can do about 40MB/s
<uvos__> sequentally
<freemangordon> d4 is another beer
<uvos__> and like 10 random
<freemangordon> HW wise those are incomparable
* sixwheeledbeast still uses spinning disks with two swap partitions on another disk...
<uvos__> so if n900 is same ballpark the increased random speed helps more than io contention hurts
<freemangordon> uvos__: afaik eMMC on n900 has very high random speed compared to uSD cards
<freemangordon> everything but 256 MB of rootfs is on eMMC
<uvos__> i have a sdcard that can saturate random writes on d4 at 100MHz bus speed
<freemangordon> wow
<uvos__> ie about 45MB/s
<uvos__> its not that special even
<uvos__> just a A2 card
<freemangordon> may I have a model? I am struggling to find a good uSD card here, no matter the price
<freemangordon> *the model
<uvos__> sure
<uvos__> but i dont have it on me rn
<freemangordon> no hurry
<uvos__> ill post it later
<freemangordon> ok
rafael2k_ has joined #maemo-leste
rafael2k has quit [Ping timeout: 252 seconds]
rafael2k__ has joined #maemo-leste
rafael2k_ has quit [Ping timeout: 255 seconds]
uvos__ has quit [Ping timeout: 255 seconds]
maemish_ has quit [Quit: Connection closed for inactivity]
<joerg> >>mmc1 has 4, mmc2 has 8<< just watch out for mmcs getting renamed, at least in fremantle
<joerg> they swap places/names/numbers
maemish_ has joined #maemo-leste
<joerg> iirc max speed on uSD in N900 always maxed out at 12.5MB/s, in line with 25MHz@4bit ?
<joerg> there are faster uSD interfaces but... prolly not for OMP34xx
<joerg> OMAP*
uvos__ has joined #maemo-leste
<uvos__> joerg: should be 50MHz (max speed of standart sdhc @ 5V) @4bit
<uvos__> practicly about 22MB/s or so with overhead
<joerg> yeah, but... maybe a signal integrity issue? I don't know
<joerg> anyway the 12some MB/s I recall quite reliably
<joerg> it's what mc etc shown me when I copied huge amounts of data to/from uSD
<joerg> possibly for write though, which must be even slower than read
<uvos__> sure your usd card must be able to saturate the bus ofc
* joerg idly wonders what uSD if any is in Iron900
<joerg> hmmm, mount doesn't suggest there's ANY uSD in my IroN900
xmn has joined #maemo-leste
<maemish_> freemangordon: How do I identify emmc swap partition?
<maemish_> And change away from using zram?
noidea_ has joined #maemo-leste
noidea_ has quit [Ping timeout: 255 seconds]
mardy has joined #maemo-leste
<buZz> maemish_: emmc swap?
noidea_ has joined #maemo-leste
<buZz> i dont think by -default- any emmc is used for swap?
<buZz> uvos__: any luck in finding that sphone selectbox issue?
<buZz> :P
<buZz> seems to default to '0'
<buZz> ah no, thats 'column' , wonder what that means in this context
<uvos__> buZz: havent looked
<uvos__> im sure its farily trivial
<buZz> yeah it must be something with that hildon_touch_selector i guess
<uvos__> maybe
<uvos__> not sure how the selector can show ofono as the current selection but then not return ofono to hildon_touch_selector_get_current_text
<uvos__> maybe we should check if the non-hildon path works
<uvos__> i gues the one in the dialer works
<uvos__> if thats it that seams like a bug in libhildon\
<uvos__> buZz: if you have the time maybe comment out that line and see what happens
<uvos__> ah i get it
<uvos__> yeah
<uvos__> so when sending a new message msg->backend is NULL
<uvos__> er uninialized
<uvos__> so we pass some random colllumb as selection
<uvos__> ofc this dosent exist
<uvos__> thats the bug
<uvos__> yeah non-hildon path works fine on my laptop
<uvos__> but the bug is in sphone in the hildon path
<buZz> hmhm
<buZz> does sphone have src packages on our repos?
<uvos__> idk
<uvos__> ;D
<uvos__> i have no idea where src packages come frome
<uvos__> i gues it should
<uvos__> ci should build one
<uvos__> idk if it gets copied to the repo or not
<uvos__> just clone it from git (imo)
<buZz> apt source sphone, works
<buZz> there's another hildon_touch_selector_set_active() in the code
<buZz> line 75
ceene has quit [Ping timeout: 255 seconds]
Danct12 has joined #maemo-leste
<buZz> i'll comment out 149 and try it
<uvos__> buZz: that ones fine
<uvos__> it just selects whatever is the first backend loaded
<uvos__> if you comment out 149 the bug should dissapear
<uvos__> but the backend wont be selected correctly if you click reply
<uvos__> (it will be the first backend instead of the one of the message)
<buZz> but i disabled commtest in sphone.ini ;)
<uvos__> sure yeah
<uvos__> it will allways be ofono
<uvos__> and atm thats the only backend anyhow
<buZz> good
<buZz> ok, got my build installed, lets see
<buZz> 'sudo reboot' really takes ages sometimes :D
k1r1t0 has quit [Read error: Connection reset by peer]
<uvos__> would have been no need for a reboot
<uvos__> killall sphone should have been enough
<buZz> thanks for the help on this btw, uvos__
<buZz> its been such a annoyance :P
<buZz> just weird that 'sudo reboot' takes so long vs 'sudo poweroff' being near instant
<uvos__> poweroff also takes long sometimes
<buZz> ahhhhh sweet, it works now \o
<buZz> with 149 commented out
<buZz> want me to PR that?
<buZz> maybe i should try it with commtest enabled again
<buZz> oh, commtest -is- enabled again :D hahaha
<uvos__> buZz: no commenting it out is not a solution
<uvos__> i need to write a real fix
<buZz> alright, either way, with that line removed its functional
<uvos__> buZz: yeah you dident follow my instructions and not edit /usr/share/sphone/sphone.inii
<uvos__> :)
<buZz> yes, i am a rebel
<buZz> :D
<uvos__> you supposed to edit ~/.sphone/sphone.ini
<uvos__> :P
<buZz> i'm just happy it works :)
<buZz> so i can finally initiated conversations
<joerg> poweroff might only fake being fast
<buZz> it seems to be legit, it can powerup aswell when it finishes
<buZz> i think i can boot whole device before a 'sudo reboot' even powers off the device :P
<buZz> s/powers off/powercycles/
<joerg> it's easy to shut off RF, LEDs and LCD
<buZz> right but you can see it being legit if you press powerbutton and motorola logo comes :)
<joerg> yep
<joerg> make sure you got no power source (USB) connected
<joerg> or "power off" may be complete fake
<buZz> yeah i rarely do
norayr has left #maemo-leste [Error from remote client]
<uvos__> poweroff dosent fake anything
<uvos__> mce (ie shutdown via power menu) fakes it a bit by instantly turning off the display
<buZz> sometimes i'm considering trying to get boot animations
<uvos__> but it keeps the status led on untill real power off
<buZz> or maybe just a bootsplash screen during kernel msgs
<uvos__> buZz: plymouth should just work ootb
<uvos__> on d4
<uvos__> so just install it
<buZz> yeah? just apt install plymouth?
<buZz> i'll try
<uvos__> and activate the service
arno11 has joined #maemo-leste
<uvos__> should work, but for early boot you would need plymouth in initramfs
<uvos__> i dont like hideing the kernel anyhow
<buZz> 'package plymouth is not available'
<uvos__> kernel messages that is
<uvos__> buZz: hmm
<buZz> i'm still on buster
<uvos__> dunno if its even in devuan
<bencoh> it is
<uvos__> cant find it on my d4 either
<uvos__> strange
<buZz> uvos__: are you on chimeara?
<uvos__> no
norayr has joined #maemo-leste
<buZz> oh ok
<buZz> maybe the package couldnt get built for arm?
<bencoh> uvos__: is there a way to disable that poweroff black screen and get system/kernel logs instead?
<uvos__> well not with this device anyhow
<uvos__> bencoh: besides using poweroff _
<bencoh> I'd rather have my device report about poweroff going awry than just a black screen
<uvos__> ?
<bencoh> uvos__: yeah
<buZz> it exists on my x86 devuan ; plymouth/stable 0.9.5-2+devuan2 amd64
<bencoh> I mean, if poweroff is the only answer it's fine
<uvos__> bencoh: no
<uvos__> not atm
<bencoh> okay
<bencoh> is poweroff really fine though, or does it skip on some stuff that leste ecosystem needs to take care of before shutdown?
<uvos__> should be fine, the shutdown dbus signal is not activated
<uvos__> but if something relies on that so hard that it causes problems its a bug
<uvos__> i dont think there is any user of this signal at all
<uvos__> besides mce and dsme
<uvos__> buZz: hmm
<Wizzup> bencoh: yes it skip stuff, but it's probably not super harmful
<buZz> Wizzup: any idea if plymouth is available on chimaera?
<buZz> (on d4)
noidea_ has quit [Ping timeout: 255 seconds]
uvos__ has quit [Ping timeout: 255 seconds]
k1r1t0 has joined #maemo-leste
uvos__ has joined #maemo-leste
rafael2k_ has joined #maemo-leste
<Wizzup> rafael2k_: do you need me to do anything for the pp atm?
<Wizzup> other than fixing the arm64 image builder for chimaera:)
rafael2k__ has quit [Ping timeout: 255 seconds]
Twig has joined #maemo-leste
<rafael2k_> nope, all good!
<rafael2k_> A suspend button in the power menu would be great (may be just triggering suspend directly)
<rafael2k_> btw, my pp keyboard did not arrive yet... but it coming
<Wizzup> check
rafael2k_ has quit [Remote host closed the connection]
noidea_ has joined #maemo-leste
noidea_ has quit [Ping timeout: 255 seconds]
noidea_ has joined #maemo-leste
cel[m]1 has joined #maemo-leste
arno11 has quit [Quit: Lost terminal]
noidea_ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
gliffy has quit [Quit: Leaving]
mardy has quit [Quit: WeeChat 3.5]
mro has joined #maemo-leste
Twig has quit [Remote host closed the connection]
mro has quit [Quit: Leaving...]
akossh has joined #maemo-leste
akossh has quit [Quit: Leaving.]
maemish_ has quit [Quit: Connection closed for inactivity]
uvos__ has quit [Ping timeout: 255 seconds]