<sicelo>
freemangordon: ah thanks. funny enough - i had seen that message, but completely forgot about it when Andreas wrote
LeePen has quit [Ping timeout: 246 seconds]
Anasko has joined #maemo-leste
Livio has joined #maemo-leste
LeePen has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
akossh has joined #maemo-leste
mdz has joined #maemo-leste
<Wizzup>
freemangordon: oh great @ wifi
Livio has quit [Ping timeout: 252 seconds]
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
ShadowJK has quit [Remote host closed the connection]
ShadowJK has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Read error: Connection reset by peer]
<freemangordon>
Wizzup: no, it is not fixed
<Wizzup>
ok
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Ping timeout: 252 seconds]
mdz has quit [Ping timeout: 252 seconds]
mdz has joined #maemo-leste
xmn has joined #maemo-leste
alexander1 has joined #maemo-leste
toly has quit [Ping timeout: 252 seconds]
Livio has joined #maemo-leste
toly has joined #maemo-leste
arno11 has joined #maemo-leste
<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
<arno11>
(or maybe i'm doing something wrong)
<arno11>
btw @wifi, i got quite similar bug on my n900 but it happens only without sim iirc
<arno11>
@hsm, yes pui 'works' without dsmetool but if i click on gps btn for example, hsm stops working
<Wizzup>
freemangordon: btw, re the python porting, the real problem is that there is no way to use gtk2 with python3
<Wizzup>
so evne if you port say python-hildon, it's mostly useless
<Wizzup>
wonder if that can assist us during the migration
<uvos>
Wizzup: no
<uvos>
Wizzup: yeah that sounds good if it works
<uvos>
one thing i wonder is how this affects the fact that on leste nokia did gconf bakwards
<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
<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.
<uvos>
same with everything else
<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
<uvos>
i wonder what this tool dose in this case
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup>
mhm, maybe we just need to bite the bullet at some point
<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?
<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
<Wizzup>
uvos: if you can prep a build I'll start it
<Wizzup>
freemangordon: for the record from my pov the wifi issue is not juts on boot, it also happens frequently after
<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
<uvos>
i mean the connection failure happens often after also
<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.
<sicelo>
maybe someday we shift to iwd :-P
<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
<sicelo>
BTW the connection issue doesn't affect N900?
<uvos>
i have never expiranced it there no?
<uvos>
s/?/.
<sicelo>
someday I might look into improving it icd-side. not making a solemn promise though
arno11 has joined #maemo-leste
<Wizzup>
tmlind: from my pov it looks like the association just fails immediately, three times in dmesg
<Wizzup>
and it fails after milliseconds, not after a sensible set of time
<Wizzup>
uvos/sicelo: it's not a problem in icd2, it's in the driver/kernel
<arno11>
sicelo: cool ! @charger
<sicelo>
arno11: I'm looking forward to have you test :-)
<arno11>
np :)
<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
<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
mdz has quit [Ping timeout: 276 seconds]
<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
<tmlind>
ok different issue then
<tmlind>
the issue i'm describing is related to device not connecting to wlan automatically after boot if not enough entropy
<Wizzup>
check
<Wizzup>
what I mean is this:
<Wizzup>
[17366.187713] wlan0: authenticate with 7c:77:16:35:f5:c1
<Wizzup>
[17366.220886] wlan0: send auth to 7c:77:16:35:f5:c1 (try 3/3)
<Wizzup>
[17366.198211] wlan0: send auth to 7c:77:16:35:f5:c1 (try 1/3)
<Wizzup>
[17366.210052] wlan0: send auth to 7c:77:16:35:f5:c1 (try 2/3)
<Wizzup>
[17366.231414] wlan0: authentication with 7c:77:16:35:f5:c1 timed out
<Wizzup>
see hoe quickly the auth times out - within 40ms of starting the authentication, and that's three attempts even
<Wizzup>
how quickly*
<tmlind>
hmm ok
<Wizzup>
here is a working one 15 seconds later:
<Wizzup>
[17384.560638] wlan0: authenticate with 7c:77:16:35:f5:c1
<Wizzup>
[17384.580078] wlan0: authenticated
<Wizzup>
[17384.575073] wlan0: send auth to 7c:77:16:35:f5:c1 (try 1/3)
<Wizzup>
[17384.590179] wlan0: associate with 7c:77:16:35:f5:c1 (try 1/3)
<Wizzup>
[17384.598358] wlan0: RX AssocResp from 7c:77:16:35:f5:c1 (capab=0x1c11 status=0 aid=3)
<Wizzup>
[17384.611450] wlcore: Association completed.
<tmlind>
maybe run wpa_supplicant in the foreground to log it?
<tmlind>
in the verbose mode
<Wizzup>
can do, from what I recall it doesn't get anything meaninful, but that was maybe 2 years ago at this point
<tmlind>
ok
<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...
<tmlind>
i guess the kernel could run out of entropy during runtime too, should see something in the dmesg
<Wizzup>
I think I remember toying with wl12xx_debug_level, let me check irc logs
<tmlind>
and you do have separate wl12xx mac addresses for each device set with the tool from uvos?
<tmlind>
duplicate mac addresses could cause issues like you're describing..
<sicelo>
I also see those issues, and have exactly one D4 ;-)
<tmlind>
ok
<Wizzup>
yeah it happens on all the mapphones I think
<Wizzup>
maybe it's related to a force country code, like with iw get reg
Anasko has quit [Remote host closed the connection]
DFP has quit [Quit: Leaving]
Anasko has joined #maemo-leste
<tmlind>
now that i think about it, it was my mz617 where wl12xx did not often connect on boot while my d4 was connecting
<Wizzup>
if it didn't connect on boot, might be worth checking if you see the same early auth aborts in dmesg
<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
<tmlind>
might be a good idea to add something like that anyways for devices with no hw rng available
<Wizzup>
perhaps haveged can also help
<Wizzup>
heh iio seems clever too :)
<tmlind>
not sure if the sha256sum makes any difference there
<tmlind>
anyways, that made my mz617 to connect on boot
<uvos>
oh i thought the kernel uses sensors for rng anyhow - like it dose input devices
<tmlind>
yeah but nothing reads them on boot
<uvos>
i see
<uvos>
i gues i expected the kernel to just read them if it finds itself out of entropy
<uvos>
so til
<tmlind>
uvos: actually looks like iio devices need to add it? see git grep add_device_randomness drivers/iio/
<tmlind>
i guess we could also automatically read some data on the iio driver probe
<tmlind>
but nothing would still ensure iio would be loaded before wl12xx..
akossh has quit [Quit: Leaving.]
<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
akossh has joined #maemo-leste
<freemangordon>
arno11: don't follow, did you made the change I asked for?
<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
<arno11>
i already tried
<arno11>
same result
<freemangordon>
did you try with a different file name?
<arno11>
yep
<freemangordon>
maybe you have some remnant from previous tries that overwrite hsm.log
<arno11>
i already check
<freemangordon>
see, with DEBUG_OUTPUT=1, h-s-m writes to console
<freemangordon>
there is no way for that to not work if written properly
<arno11>
agree
<freemangordon>
so, please pastebin the content of /etc/X11/Xsession.post/15hildon-status-menu
<arno11>
if you want
Anasko has quit [Remote host closed the connection]
<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
<Wizzup>
ah
Livio has quit [Read error: Connection reset by peer]
Livio has joined #maemo-leste
DFP has joined #maemo-leste
<arno11>
Wizzup: outgoing works on another network on my device :)
<arno11>
too happy
<Wizzup>
I still have to do more testing of this and also experience that feeling :D
<arno11>
ok :)
<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
<Wizzup>
oops
<Wizzup>
(I fixed it now obviously)
<uvos>
Wizzup: whats the use of mz617-tiny-bootstrap supposed to be?
<Wizzup>
that's the image that you can flash to install leste to the main partition
<Wizzup>
but in its current form you can't just flash it
<uvos>
yeah but its not fit for puropse
<uvos>
unless i missunderstand
<Wizzup>
not yet, no
<uvos>
the only partition flashable via fastboot that is large enough is cache at 850 ish mb
<uvos>
but this image's fs is 3Gigs in size and its 2 partitons
<uvos>
Wizzup: ok gotcha
<Wizzup>
well yes but the 3GB aren't all used
<Wizzup>
it's close to what it is supposed to be, but it's not it...yet
<uvos>
sure but i was expecting this to be an image that can be "fastboot flash cache image.img "
<Wizzup>
yeah.
<Wizzup>
maybe you can try massaging it for this purpose
<Wizzup>
I think it just needs a small amount of losetup (loopback) massaging
<uvos>
i hosed my mz617 again :P
<Wizzup>
uf :D
<Wizzup>
do you still have my manually made img?
<uvos>
im manually makeing an img from the tiny image
<Wizzup>
ok, pls record the steps
<uvos>
its not hard just create a 850mb fs and copy both boot and root there
<Wizzup>
yeah that works too
<uvos>
im not shure how the image builder works at all
<uvos>
but i think this should be fairly trivial to do or?