[09:48] <cooloney_> NCommander: sorry, i missed the Mobile team IRC meeting last night,
[09:48] <cooloney_> NCommander: is there any important thing for me?
[10:37] <asac> cooloney_: hi
[11:45] <lool> ogra: Do you manage to run the current versatile lucid linux-image kernel in qemu-system-arm?
[11:46] <ogra> lool, havent tried yet but i plan to add a download function for the package to the lucid rootstock so i'll test soon
[11:46] <lool> ogra: Would you mind pinging me when you look into this?
[11:46] <ogra> will do
[11:46] <lool> I couldn't get any video output or serial console output from it after Uncompressing linjux
[11:46] <ogra> do you have probs with it ?
[11:46] <ogra> oh
[11:51] <lool> ogra: You don't have the modules for the kernels on your people.ubuntu.com pages?
[11:51] <ogra> i dont think so
[11:52] <lool> Sadly your cortex-a8 versatile kernel is missing some modules (not sure which) and mountall doesn't like that
[11:53] <lool> These are also missing on x86, so they might be purposedly configured as modules in Ubuntu kernels in general
[11:53] <ogra> right, i'll switch to the packaged lucid kernel for all cortex-a8 variants soon
[11:53] <ogra> but indeed that requires that it works
[12:55] <asac> ericm_: apw: dove kernel failed ( i guess you noticed)
[12:56] <apw> asac, FTBFS ?
[12:56] <ericm_> asac, 'm lookin into that
[12:56] <asac> yes
[12:56] <asac> ftbfs
[12:56] <asac> thanks ericm_
[12:56] <apw> ericm_, asac i've already uploaded a fix for it
[12:56] <apw> https://edge.launchpad.net/ubuntu/+source/linux-mvl-dove/2.6.32-200.6
[12:57] <ericm_> missing module ecb
[12:57] <ericm_> command exited with status 1
[12:57] <ericm_> make[2]: *** [do-binary-udebs] Error 2
[12:57] <ericm_> make[1]: *** [binary-udebs] Error 2
[12:57] <ericm_> make: *** [binary-arch] Error 2
[12:57] <ericm_> dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2
[12:57] <ericm_> apw, thanks
[12:58] <asac> apw: great. sorry for the noise ;)
[12:58] <apw> ericm_, np ... just a stupid d-i interaction that we don't test well before upload
[12:58] <apw> i've tested udeb generation on this one
[12:58] <asac> sounds good
[12:58] <ericm_> cool
[12:58] <apw> asac, np better you tell me and i'm already doing it than not
[12:58] <cooloney> asac: i am back
[12:59] <apw> i have a lot of kernels in flight right now
[13:00] <asac> cooloney: hi.
[13:00] <asac> cooloney: wanted to touch base with you on NEON status
[13:00] <asac> cooloney: so dmart pointed out that just exporting diffferent hwcaps based on board revision might not be good enough
[13:00] <asac> e.g. user space apps could trash the board
[13:01] <asac> any ideas?
[13:01] <ogra> asac, hmm ? the patch was already uploaded :)
[13:01] <ogra> its looking at the board revision number
[13:01] <ogra> and only enables it on 3.0's
[13:01] <asac> right. but what does it do
[13:02] <asac> does it fully disable NEON if board is too old in kernel
[13:02] <ogra> export the neon flag
[13:02] <asac> or just tweaks hwcaps
[13:02] <ogra> it disables the cpu flag
[13:02] <ogra> -               if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
[13:02] <ogra> +               if (((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
[13:02] <ogra> +                       && cpu_is_mx51_rev(CHIP_REV_3_0) > 0)
[13:02] <ogra>                         elf_hwcap |= HWCAP_NEON;
[13:02] <ogra> hwcaps
[13:03] <cooloney> ogra: right
[13:03] <cooloney> asac: ogra is right,
[13:04] <asac> right. so thats the point
[13:05] <asac> someone might argue its a security issue (DoS) that user space apps can run NEON instructions without getting a SIGILL on boards that dont support it
[13:05] <asac> that was the argument made yesterday
[13:05] <cooloney> asac: generally, there is no 'neon' when you run 'cat /proc/cpuinfo' on TO2 or TO1
[13:06] <asac> cooloney: yes, but apps can still do it ... e.g. it doesnt cause  a SIGILL
[13:06] <lool> Worse, it can actually hang the board
[13:07] <asac> lool: thats the consequence e.g. the DoS i talked about above
[13:08] <asac> cooloney: how hard would it be to make it so the kernel behaves as if CONFIG_NEON=n if its an old board?
[13:08] <cooloney> asac and lool, right, probablly
[13:09] <ericm_> asac, is the gvfs crash issue filed on LP?
[13:09] <cooloney> asac: if CONFIG_NEON=y, it will enable some assemble code which is hard to do dynamical disable.
[13:10] <cooloney> asac: but I will check them later
[13:10] <NCommander> cooloney, what does this code do specifically?
[13:11] <ogra> cooloney, would you see a prob if we enabled CONFIG_TIMER_STATS and CONFIG_HPET_TIMER on imx51 and dove ? powertop would like to have these
[13:12] <ericm_> CONFIG_TIMER_STATS has been enabled on Dove
[13:12] <ericm_> lemme check HPET
[13:12] <ogra> ah, imx51 seems to not have it
[13:12] <cooloney> ogra: OK, i will check them on imx51
[13:12] <ogra> want a bug for it ?
[13:13] <ericm_> ogra, sure - file both for imx51 and dove so we can check
[13:13] <ogra> well, probably better since i can link it to the spec
[13:13] <ogra> right
[13:13] <ericm_> ogra, not sure HPET_TIMER or HIGH_RES_TIMERS
[13:13] <ericm_> but HPET_TIMER sounds to me like x86?
[13:13] <ogra> powertop moans about HPET_TIMER
[13:13] <ogra> well ...
[13:14] <ogra> its an inel app :)
[13:14] <ogra> *intel
[13:14] <ericm_> right, checked again: arch/x86/Kconfig:config HPET_TIMER
[13:14] <ericm_> mmm... maybe we need to figure out the dependency of powertop over HPET_TIMER now
[13:14] <ogra> ok, then we only wasnt TIMER_STATS
[13:14] <ogra> no
[13:15] <ogra> its HPET_TIMER is just a suggestion it makes
[13:15] <ericm_> ok
[13:15] <ogra> TIMER_STATS is actually needed for it to work
[13:16] <ericm_> ogra, ok - file one for dove as well so we can check if that's working all right in 200.6
[13:16] <ericm_> thanks
[13:17] <ogra> will we have new uploads before next alpha ?
[13:17] <cooloney> NCommander: those .S code of NEON is in arch/arm/kernel/entry-armv.S
[13:17] <ogra> else i wont target it to a milestone
[13:18] <cooloney> NCommander: generally, it will handle some NEON code and call neon version handler for VFP
[13:19] <NCommander> cooloney, my ARM ASM is a bit rusty, but we should be able to stuff a check in there to dynamically determine if its a TO1/TO2 board, and jump past the NEON access code
[13:21] <cooloney> NCommander: right, I know that, but still need to find a way to determine that. heh
[13:21] <NCommander> ogra, is there a way in userland to determine if its a TO1/2 board, or if its a TO3 board
[13:21] <ogra> NCommander, did you test suspend/resume on the dove =
[13:22] <ogra> NCommander, /proc/cpuinfo
[13:22] <ogra> the revision string
[13:22] <NCommander> ogra, not yet
[13:22] <ogra> NCommander, would be nice if you did and checked if it works from deskop menu (that would prove the pm-utils scripts work correctly)
[13:23] <NCommander> ogra, assuming I can even get to the desktop
[13:23] <ogra> on imx51 there are no issues so i'm inclined to say they work fine but i need confirmation from dove too
[13:23] <ogra> i thought the desktop works now for a while
[13:23] <ogra> at least thats what i heard about the recent liveimages
[13:24] <ogra> if you manage to click before the panel crashes it should work as a test :)
[13:25] <ogra> NCommander, i see "dove kernel to be uploaded with CONFIG_HIBERNATION set: TODO" on the pm spec, didnt that happen already ?
[13:26] <ericm_> suspend/resume on dove still have a regression, yet I believe it's because I'm still using a DDR2 DIMM here
[13:26] <ericm_> NCommander, you have a DDR3 DIMM with you, which you may help test a bit
[13:26] <NCommander> ericm_, I have DDR2 systems.
[13:26] <NCommander> I think GrueMaster has a DDR3 Dove
[13:27] <ogra> ericm_, but was CONFIG_HIBERNATION set in the config ?
[13:27] <ogra> i see no changelog entry saying so
[13:28] <ogra> ericm_, Bug #502983
[13:28] <ubot4> Launchpad bug 502983 in linux-mvl-dove "CONFIG_HIBERNATION needs to be set for dove kernels" [Undecided,Confirmed] https://launchpad.net/bugs/502983
[13:31] <ericm_> ogra, never succeeded in resuming from hibernation, yet Marvell engineer thought it works
[13:32] <ogra> well, either say its unsupported and close the bug or lets fix it :)
[13:32] <ericm_> ogra, same reason - I'd suspect a regression in DDR re-initialization which only valid for DDR3
[13:32] <ogra> i just want the spec item gone :)
[13:32] <ericm_> ogra, think I'll fix it
[13:32] <ogra> ok
[13:34] <ericm_> anyone knows how to upload the existing crash report to LP?
[13:34] <NCommander> ericm_, use ubuntu-bug *crash-file*  on the machine it happened
[13:34] <ogra> apport has some commandline switch to attach to bugs iirc
[13:35] <ericm_> NCommander, 'k
[13:35] <ogra> NCommander, for your "[mcasadevall] check cpufreq functionallity on all boards (1 day): TODO"
[13:36] <ogra> root@babbage2:~# echo powersave >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[13:36] <ogra> root@babbage2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[13:36] <ogra> powersave
[13:36] <ogra> root@babbage2:~# cat /proc/cpuinfo |grep Bogo
[13:36] <ogra> BogoMIPS	: 159.90
[13:36] <NCommander> cooloney, you can get the machine_id for an ARM chip with the mrc instruction, or by using the read_cpuid_id function
[13:36] <NCommander> (in the kernel of course)
[13:36] <ogra> root@babbage2:~# echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[13:36] <ogra> root@babbage2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[13:36] <ogra> ondemand
[13:36] <ogra> root@babbage2:~# cat /proc/cpuinfo |grep Bogo
[13:36] <ogra> BogoMIPS	: 799.53
[13:36] <NCommander> ogra, I assume I need a lucid userland for that?
[13:36] <ogra> NCommander, can you do the same on a dove
[13:36] <ogra> yes
[13:36] <NCommander> ugh
[13:37]  * NCommander has been trying not to use a lucid userland but a lucid chroot
[13:37] <ogra> come on, boot a liveimage
[13:37] <NCommander> ogra, let me grab one and I'll test
[13:37] <ogra> takes a minute to test that and we're done with the spec item
[13:37] <ogra> and make asac happy :)
[13:37] <ogra> lets get below trendline before sprint ! :)
[13:38] <NCommander> \ooo/
[13:38] <NCommander> ogra, download in progress
[13:38] <ogra> download ?
[13:38] <ogra> you dont have one locally ?
[13:38] <NCommander> ogra, I need to get a recent live image
[13:38] <NCommander> I'm zsyncing it
[13:39]  * NCommander 3> zsync
[13:39] <ogra> GrueMaster, !
[13:41]  * NCommander has his ia64 dualbooting Debian and Ubuntu
[13:41]  * NCommander feels he's playing with powers that should better be left alone ...
[13:41]  * ogra points NCommander to #ubuntu-ia64 :P
[13:41] <NCommander> ogra, its lonely there :-P
[13:42] <ogra> i can imagine
[13:42] <ericm_> Mmmm...., cpufreq on dove actually turned on by command line "cpufreq_enable"
[13:42] <ogra> can we turn that on by default ?
[13:43] <ericm_> ogra, sure
[13:43] <ogra> in kernel i mean
[13:43] <ogra> afaik initramfs tries to switch them
[13:43] <ericm_> yes, it's just controlled by a simple variable
[13:43] <ogra> to speed up the boot
[13:43] <ericm_> I'll try to file a bug report and patch for that
[13:43] <ogra> i.e. we start with performance until the rootfs is up and then switch to ondemand iirc
[13:44] <ogra> thanks
[13:44] <ericm_> np
[13:44] <ogra> ericm_, can you give me the bugnumber if you are done so i can add it to the spec
[13:44] <ogra> (done filing i mean)
[13:44] <ericm_> sure
[13:44] <ericm_> moment
[13:44] <ogra> thanks :)
[13:47] <asac> chroot: cannot run command `debootstrap/debootstrap': Exec format error
[13:47] <asac> still getting that even with binfmt_misc
[13:47] <ogra> try a distro kernel
[13:48] <ogra> i'm pretty sure there are bits missing in the vanilla build
[13:48] <ogra> there is a procps value that needs to be set, vanilla might not allow that
[13:48] <asac> ogra: you mean the kernel i am running?
[13:48] <ogra> yes
[13:49] <asac> ogra: i am running an ubuntu kernel
[13:49] <asac> Linux tinya 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux
[13:49] <ericm_> ogra, bug 513254
[13:49] <ubot4> Launchpad bug 513254 in linux-mvl-dove "[dove] CPUFREQ isn't turned on by default" [Undecided,New] https://launchpad.net/bugs/513254
[13:50] <ogra> thanks so much !
[13:50] <ericm_> np
[13:54] <ogra> asac, so i'd say the pm spec looks a lot better now
[13:55] <asac> ogra: you updated the items?
[13:55] <asac> already talked to jk?
[13:55] <ogra> yes
[13:55] <ogra> nope
[13:55] <ogra> just DONE'd the low hanging fruits
[13:55] <asac> ok i have that on my list still
[13:55] <asac> great!!
[13:56]  * asac will upgrade laptop to lucid today he thinks
[13:56]  * ogra too i want lucid at the sprint
[13:57] <ogra> but i'm scared a bit
[13:57] <asac> ogra: i will let you know ;)
[13:57] <asac> how it works out
[13:57] <ogra> ok
[13:57] <asac> have to finish my calls today first
[13:58] <asac> but then i can risk the upgrade ;)
[13:58] <ogra> i'm not even on latest karmic though
[13:58] <ogra> i should probably first enable -updates  and go to the most recent packages :)
[13:58]  * ogra does that
[13:58] <asac> for me its really scary because i didnt upgrade that late in the past
[13:59] <asac> always feels safer to upgrade in small chunks than going for the big jump ;)
[13:59] <asac> even though the ground might be more solid
[13:59] <ogra> yeah, same here
[13:59] <ogra> i usually upgrade during A1
[13:59] <asac> right. thats what i feel comfortable with too
[14:01] <ogra> oooouff
[14:01] <ogra> 287 packages
[14:27] <armin76> asac: get me a pass for mwc :)
[14:30] <suihkulokki> armin76: unless you regularry wear a tie mwc is very boring
[14:31] <armin76> suihkulokki: but i can get boards! :P
[14:32] <armin76> zumbi: you going to mwc?
[14:37] <zumbi> armin76: mwc? what is it? i am going to fosdem, btw
[14:37] <zumbi> suihkulokki: fosdem this year?
[14:38] <armin76> zumbi: mobile world congress
[14:38] <suihkulokki> neither..
[14:39] <suihkulokki> see you both in debconf10 ;)
[14:39] <zumbi> suihkulokki: we'll miss you then
[14:43] <NCommander> suihkulokki, ooh, lucky. MWC will be fun
[14:44]  * NCommander is looking forward to commuting to his second debconf
[15:37] <zumbi> armin76: i do not think i am going to mwc, but if you get tickets I can partner you, just to kill the curiosity of the newer fancy screen devices
[15:37] <zumbi> armin76: btw, attending debconf this year?
[15:51]  * ogra dist-upgrades to see if he can reproduce plars' nautilus crash
[15:53] <plars> ogra: yes, it's not good.  Trying to see if I can manually get a backtrace right now, but not having much luck finding the right -dbg packages to pull in
[15:54] <ogra> plars, i definately dont get nautilus in my upgrade
[15:54] <ogra> http://paste.ubuntu.com/363941/
[15:55] <ogra> i suspect its rather one of the libs
[15:55] <ogra> libglib2.0-0 smells like a good candidate here
[15:55] <ogra> plars, oh
[15:56] <ogra> plars, can you check the version of libgtk2.0-common vs the libgtk2.0 package ?
[15:56] <ogra> i think common is arch: all  and gtk itself ftbfs
[15:56] <ogra> so that could be our issue
[15:58] <plars> yes, could be
[15:58] <plars> libgtk2.0-0                          2.19.3-1ubuntu4
[15:58] <plars> libgtk2.0-common                     2.19.4-1ubuntu1
[15:58] <GrueMaster> ogra: what?
[15:58] <ogra> aha
[15:59] <ogra> GrueMaster, nothing anymore, i wanted to ask you for a quick cpufreq test on dove but it turned out its not yet enabled in kernel
[15:59] <GrueMaster> ok
[15:59]  * GrueMaster needs to remember to have a discussion on time zones during sprint.
[16:01] <ogra> GrueMaster, yeah, i only checked my clock after i pinged, sorry :)
[16:09] <plars> GrueMaster: I thought we agreed to abolish them?
[16:10] <GrueMaster> I must have missed that memo (like so many others).
[16:35] <armin76> zumbi: nope
[16:36] <armin76> why do i want to go to a debian conf? :P
[16:41] <zumbi> armin76: to meet NCommander et al., so you can ask for boards more effective
[16:42] <NCommander> zumbi, you going to be at debconf 10?
[16:42] <armin76> zumbi: you can ask on my behalf :D
[16:43] <zumbi> NCommander: probably, i am thinking to get tickets rather soonish than later that it'll be omre expensive. I am unsure if dates are already fixed
[16:43] <NCommander> zumbi, the dates are fixed to my knowledge
[16:43] <NCommander> armin76, just wait for the new Sheevaplug ;-)
[16:43] <zumbi> armin76: they know me, so they do not send me anything.. too slugish.. :-P
[16:44] <armin76> NCommander: i don't want to!
[16:44] <zumbi> NCommander: how are new sheevas? do they come with eSATA? or add wifi?
[16:45]  * zumbi kicks armin76 to NYC
[16:45] <NCommander> zumbi, I dunno, haven't seem then yet
[16:45]  * NCommander steals armin76's SPARC and ia64 systems
[16:45] <NCommander> bahaha
[16:47] <zumbi> http://www.linuxfordevices.com/c/a/News/Marvell-Plug-Computer-30-and-Armada-300-and-610/
[16:48]  * zumbi wants http://www.linuxfordevices.com/c/a/News/Mindspeed-Transcede-T4000-and-T4020/
[17:04] <zumbi> armin76: last processors are shown at mwc. If you persuade somebody for tickets
[17:09] <plars> ogra: downgrading libgtk2.0-common didn't help anything either
[17:11] <plars> ogra: in case you missed my last...
[17:11] <plars> ogra: downgrading libgtk2.0-common didn't help anything either
[17:12] <ogra> yes, i know
[17:12] <ogra> see -devel
[17:12] <ogra> i did that
[17:12]  * ogra somehow had a complete network breakdown over here 
[17:14] <plars> ogra: ah, I saw that you had tried glib and gnome-session, wasn't sure about others
[17:15] <ogra> i i actually upgraded gtk :)
[17:15] <ogra> manually pulling debs from LP
[17:15] <ogra> but its surely not get
[17:16] <ogra> gtk
[17:16] <ogra> sigh, that focus stealing of update-manager is annoying
[17:31] <plars> ogra: got it
[17:31] <plars> ogra: gvfs
[17:31] <plars> ogra: looks to be probably libgvfscommon0
[18:35] <NCommander> Apple finally announced a tablet
[18:35] <NCommander> O_o;
[18:35] <Stskeeps> it's kinda disappointing.
[18:35] <ojn> haha
[18:36] <Stskeeps> and embarassing from a ui invention and technical pov (check their pixel doubling to fit native iphone apps..)
[18:36] <ojn> stskeeps: what else could they have done?
[18:37] <ojn> I bet most apps will be updated to handle the new screen, it's just a stopgap thing.
[18:37] <Stskeeps> ojn: it looks like a cheap copy of moblin.
[18:37] <persia> Pity they went for such a low DPI.  Historically they've been pretty good at making sure stuff renders sharply.
[18:37] <ojn> persia: apple has always been low-dpi. they're behind most other PC desktops/laptops on dpi as well.
[18:38] <ojn> stskeeps: ah, you're a maemo guy. that explains the bitterness. :)
[18:38] <persia> ojn: Hrm?  That's not been my experience.  Mind you, I went and got the special 300DPI handheld from Sharp back when it came out, but in terms of mainstream stuff they seem to go for higher DPI than other companies.
[18:39] <ojn> persia: not for laptops. Took them forever to come out with a 1440x900 15" laptop, and they're still at that resolution for those screens. 17" has a highres option though.
[18:39] <persia> ojn: Hrm.  Strange.  I haven't looked at their laptops in a *long* time, but the marketing materials still talk about high-DPI.
[18:40] <ojn> everything is relative. It's quite appropriate DPI for most things, I'm not complaining. But thinkpads and some other brands have quite a bit higher resolution screens. Too high for some use, I would say. But nice for programming
[18:40] <persia> Oh well, I guess the low DPI is in line with other things then :)
[18:40] <persia> There is no such thing as too much DPI : you just get better rendering :)
[18:41] <ojn> right, and bigger fonts. and apps that handle that nicely (and that's the catch, not all do)
[18:41] <persia> Those are bugs :)
[18:41] <persia> But the fonts should be the same size.  Those are supposed to be defined in ems not pixels.
[18:42] <persia> Or points, but that's related to ems.
[19:13] <armin76> rabeeh: get me a pass for mwc2010!