[08:40] <hrw> morning
[10:48] <saeed> persia: ping
[10:51] <persia> saeed: ?
[10:51] <saeed> persia hey
[10:51] <saeed> does hibernate work for you on dove?
[10:52] <persia> I don't have a dove board, so both "yes" and "no" seem like the wrong answer to that :)
[10:53] <saeed> anyway, I noticed that sound settings are not restored after hibernate
[10:53] <JamieBennett> persia: saeed: going by what was said in the meeting yesterday, no would be the right answer
[10:53] <persia> saeed: Which sound settings?
[10:54] <saeed> volume, mute, etc
[10:54] <saeed> I mean hw settings
[10:54] <persia> Ah, hrm.
[10:55] <persia> ericm_: Any ideas?
[10:55] <saeed> which part of the system should restore those settings after hibernate resume?
[10:56] <hrw> saeed: add "/etc/init.d/alsa start" to after-resume scripts?
[10:57] <saeed> hrw: where are those scripts located?
[10:57] <persia> /etc/pm/sleep.d/ but I don't see any on my lucid installs, making me thing there is another solution somewhere
[10:57] <hrw> saeed: no idea - I do not have any machine running ubuntu
[10:58] <lool> hrw: Let us limit discussions to Ubuntu approaches here though  ;-)
[10:58] <hrw> monday will be funny day - working on ubuntu/arm without having usable machine for it
[10:58] <lool> hrw: Eh, you don't have any laptop/desktop running Ubuntu?
[10:59] <hrw> lool: Debian on desktop, Debian on laptop
[10:59] <XorA> if does is an ASoC board then ASoC layer should restore sound exactly as is
[10:59] <XorA> dove
[10:59] <lool> hrw: I personally dual boot Debian on my laptop
[10:59] <lool> With a shared /home
[10:59] <hrw> lool: with 80GB hdd I have dual boot Debian/winxppro
[11:00] <hrw> considering buying asus ul30 as new platform so kubuntu will land there rather
[11:00] <persia> XorA: so `/sbin/alsa --force-reload` shouldn't be required?
[11:01] <saeed> XorA: the dove has two sound cards (AC97 and i2s), both of them are asoc
[11:01] <kaouthia> lool: Do you use Ext2fsd?
[11:01] <XorA> persia: no, the machine/codec driver should restore
[11:01]  * XorA doesnt have a dove or even know what it is
[11:01] <lool> kaouthia: No
[11:01] <persia> That explains the lack of /etc/pm/sleep.d/50alsa in lucid.
[11:01] <XorA> but I did used to maintain ASoC
[11:01] <lool> never heard of it
[11:01] <kaouthia> How do you access your /home from your windows partition?
[11:02] <lool> kaouthia: I dont use windows
[11:02] <XorA> hrw: I do my ubuntu work on fedora here :-D
[11:02] <lool> it's a dual boot of debian and ubuntu
[11:02] <kaouthia> lool: Ah okay
[11:02]  * lool needs to disappear for an hour
[11:02] <hrw> lool: both reside on same crypted lvm?
[11:02] <persia> XorA: How does that work?  I didn't know most of our development scripts were available for Fedora (or do you work in a chroot/VM)?
[11:03] <persia> hrw: No reason they couldn't, given appropriate bootargs
[11:06] <XorA> persia: VM combined with native on zoom2 board
[11:06] <persia> XorA: ah, yeah, VM is plenty sufficient.
[11:07] <persia> Is the Zoom2 fast enough to use for development directly?  I was under the impression it was a bit RAM-low.
[11:07] <saeed> XorA: can you explain how should machine/codec restore settings after hibernate?
[11:08] <XorA> persia: I recompiled xf86-video-omapfb with no real issues, havent tried kernel yet
[11:08] <XorA> saeed: look at the drivers in sound/soc/*
[11:08] <persia> No need: that you are using it for that indicates it's sufficient :)
[11:09] <saeed> XorA: what I'm missing, is how can the driver get those parametes from?
[11:09] <XorA> saeed: because the driver wrote them to the codec
[11:09] <XorA> saeed: it remembers themk
[11:10] <saeed> XorA: but after hibernate, the driver will be loaded as from reboot
[11:12] <XorA> saeed: Im not very familiar with ubuntu on arm, I work on a different distro where we dont power down the chips
[11:13] <saeed> XorA: but hibernate usually powers down the system, right?
[11:14] <persia> Indeed.  That's the usual difference between "suspend" and "hibernate".
[11:14] <saeed> XorA; please note the resuming from standby (suspend to ram) works fine to me
[11:15]  * XorA has never hibernated an arm in that case
[11:15] <saeed> XorA: I think it's the same on x86
[11:15] <hrw> hibernate as susped-to-disk-and-power-off?
[11:15] <saeed> yes
[11:16] <hrw> never did that on arm either
[11:16] <saeed> actually mainline kernel doesn't support that, we have added that functionality
[11:16] <persia> On boot, we seem to use /sbin/alsa-utils to restore state with alsactl.
[11:17] <XorA> hrw: ever feel we have walked into a strange new world :-)
[11:17] <persia> Might need support for that around hibernate in pm-utils
[11:17] <persia> saeed: Do you know if it works on x86? with Ubuntu?  You might be hitting a general bug.
[11:18] <persia> (or powerpc)
[11:18] <saeed> persia: no
[11:19] <hrw> XorA: life without new challenges starts to be boring
[11:20] <persia> https://help.ubuntu.com/community/SoundTroubleshooting definitely has notes on working around hibernation issues.
[11:20] <hrw> XorA: I returned from fosdem with devboard which I did not even connected serial yet
[11:20] <XorA> hrw: hehe
[11:20] <hrw> XorA: thinking about giving it for a friend as a gift
[11:20]  * XorA is just trying to fix the zoom2 kernel so serial is not needed
[11:21] <hrw> nice improvement over arm7tdmi which are high tech at his company ;D
[11:21] <ogra> XorA, have you seen bug 567260 ?
[11:21] <ubot4> Launchpad bug 567260 in xf86-video-omapfb (Ubuntu) "xserver-xorg-video-omap* fail due to no /dev/fb (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/567260
[11:22] <XorA> ogra: thats what I fixed
[11:22] <ogra> we have another two days for a fix
[11:22] <persia> saeed: Do you also lose settings on reboot?
[11:22] <XorA> ogra: I can post patch to bug
[11:22] <ogra> so it if it goes into archive tomorrow or friday we can have it in final
[11:22] <saeed> persia: no
[11:22] <XorA> its a one liner
[11:22] <ogra> XorA, cool, please do so
[11:22]  * persia looks for another bug
[11:22] <XorA> gimme a few mins to replace kernel on zoom2 to extract bug
[11:23] <hrw> oneliners are usually the most amazing changes
[11:23] <hrw> I remember curses of one developer after his 4 hours of attempts to solve build error which I solved with oneliner for makefile
[11:24] <ogra> persia, you want a bug ? i have plenty
[11:25] <persia> ogra: Do you have one about sound and hibernate?
[11:25]  * persia is looking for a *specific* bug
[11:25] <XorA> ogra: that bug is already detailing my one liner
[11:25] <persia> saeed: Try adding /etc/pm/sleep.d/50alsa as indicated at https://help.ubuntu.com/community/SoundTroubleshooting#Getting%20ALSA%20to%20work%20after%20suspend%20/%20hibernate and see if that works.  If not, it might give some hints on a path to resolve it.
[11:26] <ogra> persia, nope, but since i joined the installer team yesterday i can provide you with 100's of installer bugs if you are desperately in need for a bug :P
[11:26] <suihkulokki> hrw: one particularry fun online fix that took one day to locate..
[11:26] <suihkulokki> -char foo;
[11:27] <suihkulokki> +signed char foo;
[11:27] <persia> ogra: I have code that generates lists of unfiled bugs on a regular basis already, if I'm just hunting bugs :)
[11:28] <ogra> haha
[11:30] <saeed> persia: I'll try
[11:31] <XorA> OTG working on boot awesome
[11:31] <persia> saeed: If that doesn't work, please file a bug (`ubuntu-bug audio`)
[11:31] <ogra> XorA, which kernel ?
[11:32] <XorA> ogra: it works on all linux-omap kernels
[11:32] <XorA> ogra: specifically on my zoom2
[11:32] <ogra> XorA, not ubuntu then
[11:32] <XorA> ogra: you guys could add it
[11:33] <ogra> XorA, out kernel team uses mainline only on omap
[11:34] <ogra> tahst why the omap kernel is actually .33 and not .32 like the rest of ubuntu
[11:34] <persia> (except fsl-imx51)
[11:34] <ogra> yeah
[11:34] <XorA> ogra: your not allowed to patch at all?
[11:34] <hrw> ogra: so torvalds tree instead of linux-omap tree?
[11:34] <persia> Oh, and -rt
[11:34] <ogra> persia, which is why i said omap :)
[11:34] <ogra> hrw, right
[11:34] <ogra> XorA, we are
[11:34] <persia> ogra: "rest of ubuntu" was my picky point
[11:35] <ogra> amitk, backports/cross ports bits and pieces
[11:35] <hrw> XorA: Debian policy was: mainline kernel + backports from mainline. probably same/similar for ubuntu
[11:35] <saeed> persia: it didn't work, I'll fill a bug
[11:35] <hrw> XorA: pain for omap
[11:35] <persia> saeed: Thanks.
[11:35] <ogra> hrw, well, whatever is maintainable, if amitk decides a certain patch from -omap is valuable that will also be pulled in
[11:35] <ogra> its up to our kernel maintainer ...
[11:36] <ogra> i'm only a consumer and tester ;)
[11:36] <XorA> ogra: http://git.openembedded.net/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/0042-musb-allow-host-io-without-gadget-module.patch
[11:36] <NCommander> eggonlea: you aorund?
[11:38] <amitk> XorA: the idea is to further the mainlining of omap by using mainline kernels. I've talked to Tony about this and he agrees. linux-omap is more like a buffer to mainline.
[11:39] <XorA> amitk: I know this, linux-omap diffs have rapidly decreased over mainline
[11:39] <eggonlea> NCommander: yes.
[11:40] <amitk> and yes, i need to find time and pick out the right patches from 34-rc or linux-omap to unbreak OTG
[11:40] <XorA> amitk: see patch above :-)
[11:44] <amitk> XorA: thanks, I shall
[11:44] <XorA> amitk: Im unsure of the pushed to mainline status, but Ajay is the TI USB guy
[11:44] <hrw> amitk: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/ is worht checking anyway
[11:45]  * XorA really hopes ubuntu speeds the mainlining of zoom2/3 patches
[11:46] <ogra> zoom and beagle hopefully
[11:47] <hrw> ogra: beagleboard needs first really stable working version
[12:01]  * amitk disappears for lunch
[12:08]  * ogra lols about XorA's patch for omapfb
[12:08] <ogra> XorA, i tought you had added any kind of autodetection
[12:09] <ogra> i know asac tries to add that before final
[12:20] <XorA> ogra: I may code that up one day, but for now I just need lucid running
[12:59] <lool> hrw: ecryptfs actually
[13:02] <shashi> ogra: do you know why omapfb instead of fbdev is used as reported in 567260?
[13:03] <hrw> lool: it crypts files but not filesystem - right?
[13:03] <lool> hrw: It's a filesystem on filesystem
[13:03] <lool> so it crytps filesystem objects in filesystem objects
[13:03] <lool> e.g. a dir to a dir and a file to a file
[13:04] <hrw> ok, I prefer crypted lvm - handle also swap so I do /boot + crypto-lvm(/ + swap)
[13:10] <ogra> shashi, its not used by default atm, only if you install the omapfb package
[13:11] <shashi> ogra: ok thanks....i was inputing some comments/ thoughts in 567260
[13:12] <ogra> shashi, thanks :)
[13:14] <hrw> ok, tickets for uds bought/booked
[13:15] <ogra> clap clap clap
[13:15] <ogra> looking forward to meet you there :)
[13:18] <hrw> same
[13:24] <rcn-ee> hrw, i was looking at the musb host/device patch, haven't tested it yet, but how's it working for you?
[13:24] <hrw> rcn-ee: I did not updated my beagle to this kernel yet
[14:32] <ericm_> saeed, could you update your resume from suspend status to bug 551491?
[14:32] <ubot4> Launchpad bug 551491 in linux-mvl-dove (Ubuntu) "BSP update for Marvell Dove kernel LSP 5.1.0 (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/551491
[14:51] <ogra_beagle> WOHOO+
[14:52]  * ogra_beagle wipes this install and starts over with the latest image hoping all is fine now
[14:53] <hrw> (II) XINPUT: Adding extended input device "bmi-lcd-ts" (type: TOUCHSCREEN)
[14:53] <hrw> ;D
[14:53] <ogra> congrats
[14:54] <hrw> other omap3 board
[14:59] <amitk> hrw: what board is this?
[14:59] <hrw> bug 2.0
[14:59] <hrw> prototype
[14:59] <amitk> standard image?
[14:59] <amitk> or custom kernel?
[14:59] <hrw> no ubuntu
[15:00] <hrw> amitk: I am returning device on days so no ubuntu tests for it
[15:04] <amitk> ogra: you said something about the new image allowing me to install to sd itself?
[15:05] <ogra> amitk, the netinst one, yes
[15:06] <amitk> how do i put a custom kernel on those?
[15:06] <ogra> amitk, pos-install
[15:06] <ogra> *post
[15:06] <ogra> you cant do it in the image
[15:07] <amitk> right
[15:07] <ogra> d-i is closely built with the kernel
[15:09] <saeed> ericm_: done
[15:19] <zumbi> amitk: http://wiki.debian.org/DebianInstaller/Modify/CustomKernel
[15:19] <amitk> zumbi: ?
[15:20] <ogra> zumbi, heh, thats ancient
[15:20] <zumbi> amitk: are not you asking how to use d-i with custom kernel?
[15:20] <ogra> from a time where d-i was still on two floppies
[15:20] <amitk> zumbi: ohh right. :) thanks, i'll take a look
[15:21] <ogra> amitk, d-i changed completely ... thats even pre-ubuntu
[15:21] <zumbi> amitk: ogra is right, looks old
[15:21] <ogra> its for 2.4 kernels :)
[15:21] <zumbi> ogra: do you know a more up to date doc?
[15:21] <ogra> no
[15:21] <amitk> hehe lol
[15:21] <ogra> and its a hell lot of work even if i knew a doc
[15:21] <zumbi> amitk: i would like to have efikamx (iMX51) in mainline kernel
[15:21] <hrw> 2.4...
[15:22] <zumbi> ogra: using kernel-wedge?
[15:22] <amitk> zumbi: want to submit patches? pointers to git tree? pointer to someone that has hardware?
[15:22] <ogra> installing the existing image and just issuing dpkg -i linux-image .... *.deb is definately easier and a lot faster
[15:23] <zumbi> amitk: i have hardware, the bad thing is they use freescale SDK
[15:23] <amitk> zumbi: that is fine if you don't mind wiping it over ;)
[15:23] <zumbi> ogra: right, for efikamx, i wanted to add it to flash-kernel which hooks kernel-package
[15:24] <zumbi> ogra: then use somethin similar to rootstock
[15:24] <ogra> flash-kernel hooks kernel-package ??
[15:24] <ogra> flash-kernel is really only to set up the bootlaoder
[15:25] <ogra> you shouldnt abuse it for other stuff, rather create a new tool that flash-kernel can call
[15:25] <zumbi> flash-kernel (debian version) calls mkimage on vmlinux and initrd
[15:26] <ogra> yes
[15:26] <zumbi> I thought that was the best way to do for porting a new device
[15:26] <ogra> but it doesnt do anything with kernel-package
[15:27] <zumbi> kernel-package provides me with a vmlinux and initrd, then flash-kernel could get me the right thing I need (uBoot format)
[15:27] <ogra> and i dont think we even support kernel-package in ubuntu
[15:27] <ogra> i might be wrong though, amitk might know better
[15:27] <zumbi> kernel-package is a great tool
[15:27] <ogra> but i guess it doesnt properly hook into the ubuntu infrastructure
[15:28] <amitk> -ENOkernel-package
[15:28] <zumbi> uhm.. that's sad
[15:28] <zumbi> you don't even need a debian_dir, it creates it for you
[15:28] <ogra> yes, thats the scary part
[15:29] <amitk> zumbi: it might work for mainline kernels, but not for 'managed/supported' kernels.
[15:29] <amitk> but it is something the kernel team plans to look at in our sprint next week
[15:29] <zumbi> amitk: it works for efikamx, kirkwood sheevaplug, and some others
[15:29] <amitk> (whether we should support it or not)
[15:30] <ogra> zumbi, FSVO works
[15:30] <zumbi> what is FSVO?
[15:30] <amitk> zumbi: sure, but we don't support that HW, so why would we care? (to be blunt)
[15:30] <ogra> zumbi, as rootstock "works" to create an image
[15:30] <ogra> you will never get the same as you have with a real install with rootstock ...
[15:30] <ogra> and you will never get a proper ubuntu kernel package with kernel-package
[15:31] <ogra> so its "some system that looks like ubuntu" in the end
[15:31] <amitk> zumbi: though I would love for our kernel to support multiple boards with a single kernel tree.
[15:31] <ogra> zumbi, FSVO -> for some value of
[15:31] <zumbi> well, I would like to find a way to have an embedded-installer which suits ubuntu and debian
[15:31] <zumbi> which handles all this bootloader, kernel details
[15:32] <zumbi> but it seems hard to find a consensus
[15:32] <ogra> you cant do it with the concept of a distro
[15:33] <ogra> you can only get close to it
[15:33] <ogra> i.e. like rootstock
[15:33] <ogra> but effectively you will always have a bunch of differences to the real thing
[15:35] <zumbi> yes, it is hard to be generic.. :-/
[15:41] <persia> zumbi: At least in Ubuntu, we explicitly say we aren't building "embedded", so want d-i to just do the right thing.  This approach happens to be viable for a huge volume of hardware that others may consider "embedded".
[15:42] <persia> zumbi: Rather than building a new embedded installer, what might be helpful is improving the image modification tools in a way that one can easily swap the installed kernel.
[15:42] <persia> And improving the kernel packaging scripts to make it easy to convert an arbitrary git tree into a packaging tree.
[15:43] <saeed> NCommander: ping
[15:45] <asac> ogra: what is different compared to ubuntu if you go for a properly seeded rootstock fs and combine that with the kernel/bootloader packages?
[15:45] <persia> asac: All the base config stuff.
[15:45] <asac> persia: baseconfig like oem-config?
[15:46] <ogra> asac, debconf
[15:46] <ogra> rootstock surely doesnt seed all of debconf properly yet
[15:46] <asac> ogra: what pieces are missing there?
[15:46] <persia> asac: So, the base-config package went away, and the installer handles that.  I ended up spending many months fixing a million little issues with moblin-image-creator and we determined it was easier to make ubiquity work for MID than to continue tracking down all the special cases.
[15:46] <asac> ogra: so its a matter of tweaking seeds?
[15:46] <ogra> asac, no idea, i never made an effort to check that
[15:46] <persia> asac: No, base-config like the *REALLY OLD* debian package.
[15:47] <ogra> its a matter of integrating rootstock better with debconf
[15:47] <asac> persia: right. but thats now oem-config?
[15:47] <ogra> and using d-i modules instead of scripts
[15:47] <persia> asac: Not at all.  There is no relation between those packages.  oem-config does *some* of the configuration post-install.
[15:47] <asac> ogra: how do we know that d-i and ubiquity do all the same?
[15:47] <ogra> thats the reason why i switched to oem-config by default
[15:47] <zumbi> persia: i agree on improving the kernel packaging scripts, but which ones? (debian, ubuntu, kernel-package, kernel-wedge,.. just reate yet another one)
[15:47] <persia> But oem-config expects a d-i base install.
[15:47] <ogra> it does a good bunch of that using d-i modules
[15:47] <asac> for me it feels like there is deviation anyway, though you would call both systems "ubuntu"
[15:47] <ogra> persia, it brings it
[15:48] <ogra> and removes it after it ran
[15:48] <persia> zumbi: Ummm.  I'm going to have to defer to the #ubuntu-kernel folks at this point :)
[15:48] <ogra> asac, right, but target has to be to minimize the deviation
[15:48] <persia> ogra: No, it runs *some* d-i components.  Some stuff never gets run in oem-config.
[15:48] <ogra> asac, which the step to oem-config did for example
[15:48] <asac> ogra: right. just wanted to point out that quite a lot of details are probably not relevant for "ubuntu"
[15:49] <asac> ogra: yeah. for me a rootfs + oem-config is ubuntu ;)
[15:49] <ogra> yeah, might be
[15:49] <asac> thats how we ship stuff to production somewhere too, isnt it?
[15:49] <ogra> nobody researched yet if/what additional pieces are missing in a rootstock install
[15:49] <persia> asac: In terms of use of the "ubuntu" term, no, but we expect there to be a large number of small bugs with a rootstock-based install (just as there are many known bugs with vm-builder installs, or any other tools that aren't d-i)
[15:49] <ogra> asac, not sure, thats something only OSG can answer
[15:50] <persia> asac: Nothing called "Ubuntu" ships without a d-i installer to my knowledge.
[15:50] <ogra> right
[15:50] <persia> I know of specialised remixes that use other installers (the one for the Netwalker is an example).
[15:51] <ogra> and the proper approach for rootstock might also be to run d-i with a preseed file for the second stage
[15:51] <hrw> guys: if I boot x86-64 from 10.04b2 cd can I make bootable pendrive?
[15:51] <ogra> instead of the script it uses atm
[15:51] <persia> Doing that makes it just a normal install.
[15:51] <persia> hrw: Sure.
[15:52] <asac> persia: i would like to see those bugs ;)
[15:52] <asac> at least one example
[15:52] <ogra> asac, as i said, nobody actually researched the differences
[15:52] <persia> hrw: You might have to play some games to tell usb-creator to make the pendrive based on the cd in your drive though.
[15:52] <persia> asac: I'll dig up a URL.
[15:52] <ogra> asac, you would have to diff the debconf DB between a real install and a rootstock one
[15:53] <ogra> i'm very sure there *are* differences ... just dont knwo which
[15:54] <persia> asac: http://www.sharp.co.jp/support/ex-data/recovery.sh.tar.gz
[15:55] <persia> asac: http://www.sharp.co.jp/support/mit/doc/install.html has instructions with screenshots (in case you don't read Japanese)
[15:57] <asac> i wouldnt be able to follow that instruction ;)
[15:57] <hrw> asac: http://translate.google.com/translate?u=http%3A//www.sharp.co.jp/support/mit/doc/install.html&hl=pl&langpair=auto|en&tbb=1&ie=Shift_JIS
[15:58]  * hrw hails JS menu in bookmarks toolbar
[15:58] <persia> heh, cool.  Japanese->English translation with polish controls
[15:58] <persia> P
[15:58] <hrw> bookmarklets saves lot of time
[15:58] <hrw> persia: s/hl=pl/hl=en/?
[15:59] <persia> hrw: If I didn7t already know what the buttons did, yeah :)
[16:00] <hrw> persia: before google translate I used "Excite Japan" translator
[16:00] <hrw> it was like 'put url', select 'shelf->something', press button
[16:00] <persia> Oh, if you skip the hl= bit entirely, it chooses your default once.
[16:00] <persia> hrw: Excite Japan does a slightly better job with the text, but is less good for web pages.
[16:01] <hrw> time passed, less to do with japanese websites, so google is enough for me
[16:01] <hrw> ~curse sharp
[16:02] <plars> GrueMaster: hmm, I may have spoken too soon on the dove suspend/resume.  The first few times it worked for me but seem to be hitting a problem now
[16:02] <persia> The Netwalker is actually a nice bit of kit.
[16:02] <persia> And they seem to be supporting it some.
[16:02] <persia> No idea if it sells well enough to keep that (likely needs more overseas orders to justify worldwide release)
[16:03] <hrw> netwalker is ugly...
[16:04] <persia> Yeah, it's a bit large, and it doesn't convert, and the A key is in the wrong place, but other than that, it works.
[16:04] <hrw> and it is imx...
[16:06] <persia> Well, I guess.  I'm more interested in something I can actually put in my pocket and use than which is the best technology inside.
[16:06] <hrw> I have big aversion to xMB kernel patches
[16:06] <persia> As long as all the other SoCs aren't available as 4-5" handhelds, how cool they are isn't so important.
[16:06] <persia> I just use the stock kernel, and keep hoping someone will package a newer kernel.
[16:06] <hrw> persia: I have n900 for playing
[16:07] <persia> hrw: You don't even want to get me started about the shortcomings of that device :)
[16:07] <persia> Nice internals though.
[16:07] <hrw> persia: I just hope that netwalker team does not have anyone from zaurus teams
[16:08] <persia> I've no idea.
[16:08] <hrw> 2.4.18-crappix (OE/OZ internal name for 2.4.18-embeddix) was total disaster from sharp
[16:08] <persia> Dunno.  It ships a kernel that works with Ubuntu, which is all I require in a kernel.
[16:08] <hrw> 2.4.18 + arm + pxa + others + bunch of others + wext updates + irda updates + bunch of fixes + bunch another ones
[16:09] <hrw> and only first 4 parts were from sharp
[16:09] <persia> For this one, amitk said he managed to upstream most of the patches.
[16:09] <hrw> cool
[16:11]  * amitk looks up
[16:11] <zumbi> amitk: where is imx51 mainline branch?
[16:11] <amitk> zumbi: in linus's tree? :)
[16:11] <amitk> *linus'
[16:11] <zumbi> amitk: we have efikamx stuff http://gitorious.org/efikamx/linux-efikamx
[16:12] <zumbi> amitk: i do not see any mach-mx5 in linus' tree
[16:13] <amitk> 2.6.34-rc?
[16:13] <zumbi> 2.6.33 was looking via lxr
[16:13] <amitk> it went in in 2.6.34
[16:13] <zumbi> oh! ok, sorry
[16:15] <ogra> amitk, argh !
[16:15] <ogra> amitk, read error on /dev/mtd2: cannot allocate memory
[16:16] <ogra> thast where ubiquity dies now :/
[16:17] <persia> That's flash-kernel-installer
[16:18] <amitk> ogra: i thought you got mtd write working...
[16:19] <ogra> amitk, it works with d-i
[16:21] <ogra> amitk, worst is that i dont actually read at all
[16:22] <amitk> ogra: is dd able to read/write?
[16:22] <ogra> amitk, seems its fw_setenv thats failing to write
[16:22] <ogra> yes, its dd able
[16:22] <ogra> but mtd2 holds the uboot config
[16:23] <lool> ogra: Are you passing fw_setenv a mtd or a mtdblock device?
[16:23] <ogra> i only dd to ntd3 and 4
[16:23] <ogra> echo "/dev/mtd2 0x0000 0x20000 0x20000" > /target/etc/fw_env.config
[16:23] <ogra> lool, ^^^^
[16:25] <lool> sounds good
[16:25] <lool> ISTR the u-boot tools are using mtd calls for io
[16:25] <lool> which would fail on mtdblock
[16:25] <ogra> i wonder if i need to wipe it like the other ntd devices before writing
[16:25] <ogra> i dont zero it out at install time
[16:25] <ogra> which i do with mtd3 and 4
[16:27] <persia> ogra: Have you looked for smarter tools in mtd-utils than dd?
[16:27] <persia> dd isn't precisely eraseblock aware.
[16:27] <hrw> flash_eraseall + nandwrite -p?
[16:28] <hrw> first cleans mtd, second writes with padding
[16:28] <lool> ogra: Oh you're dd-ing to mtdN?
[16:29] <lool> ogra: To write kernels and initrd, you'd better write them directly to mtdblockN
[16:30] <persia> hrw: Yes, that was what I was thinking, assuming it's NAND.
[16:32] <ogra> lool, i'm just doing what all other arches in flash-kernel do
[16:32] <hrw> persia: I do not remember when last time I used NOR
[16:32] <hrw> mostly NAND or OneNAND recently
[16:32] <persia> hrw: My netwalker has redboot on NOR, but I don't have any interest in changing it, since the behaviour is sufficient for me.
[16:33] <ogra> lool, flash-kernel was minaly a copy/paste job with some adjustments
[16:33] <ogra> *mainly
[16:33] <ogra> i can reliably reproduce fw_setenv breakage though
[16:34] <ogra> andi suspect it is because uboot-envtools was never recompiled
[16:34] <persia> ogra: copy&paste of dd against NAND isn't best, even if it's the same as something else.
[16:35] <ogra> persia, it is the same code for *all* platforms in flash-kernel
[16:35] <ogra> persia, rewrite flash-kernel if you feel it behaves wrong :)
[16:35] <persia> Then I say it's all dangerous at best, and likely bad.
[16:35] <persia> Maybe, after I deal with other things.
[16:35] <ogra> i'm just using the existing functions in there
[16:35] <ogra> and flash-kernel isnt my problem
[16:35] <persia> But dd against NAND significantly reduces NAND life.
[16:36] <ogra> my problem is flash-kernel-installer
[16:39] <ogra> http://paste.ubuntu.com/419902/
[16:39] <ogra> anyone having an idea ^^^^ ?
[16:42] <ogra> amm
[16:42] <ogra> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512589
[16:42] <ubot4> Debian bug 512589 in uboot-envtools "fw_setenv: Cannot malloc -131072 bytes: Cannot allocate memory" [Normal,Fixed]
[16:48]  * ogra is desparate
[16:50] <ogra> lool, any idea ?
[16:50]  * ogra doesnt get why it works in d-i 
[16:51] <ogra> i have done about twenty netinst installs now and never hit it
[16:51] <ogra> and three -server
[16:51] <ogra> (alternate)
[16:54] <ogra> persia, btw, looking at the code, flash-kernel translates /dev/mtd to /dev/mtdblock at some point
[16:54] <ogra> so the writing goes to mtdblock
[16:55] <ndec> hi. i'd like to be mount the daily .img file on my desktop, instead of using dd to write to SD card, e.g. I want to update the kernel in the .img file. i tried mount -t vfat -o loop xxx and it does not work.  how can i do that?
[16:55]  * persia is slightly mollified
[16:55] <persia> ndec: You need to use losetup and kpartx: there are multiple partitions on the image
[16:55]  * persia digs up a reference
[16:55] <ogra> there arent
[16:55] <ogra> there is just one
[16:56] <ndec> ogra: that's what I thought...
[16:56]  * persia is confused
[16:56] <ogra> but hwat persia said is still true ... either mount with offset or use kpartx
[16:56] <persia> ndec: http://blog.dustinkirkland.com/2008/10/mounting-kvm-disk-image.html
[16:56] <ndec> ogra: what is the offset? what is the right command?
[16:56] <ogra> you need to use an offset that omits the MBR
[16:56] <persia> ogra: Ah, so there's only one partition, but it is a partition.  That makes sense.
[16:56] <ogra> i think something like -o offset,512 or some such
[16:56] <ogra> or offset=512
[16:58] <lool> ndec: use kpartx
[16:58] <persia> Oooh, `kpartx -av foo.img` is supposed to just work.  That saves effort.
[16:58] <ndec> ogra: thx. sudo mount -t vfat -o loop,offset=512 is working!
[16:58] <lool> Yes
[16:58] <persia> (remember to use `kpartx -dv foo.img` later)
[16:58] <ogra> mount -o loop,offset=512 imagefile.img /mountpoint shoudl work
[16:58] <lool> You have to losetup it first
[16:58] <amitk> ogra, why don't I see omap images here? http://cdimage.ubuntu.com/netboot/lucid/
[16:58] <persia> lool: Not according to the comments on kirkland's blog
[16:58] <ogra> amitk, because they are ports and not officially supported in lucid
[16:59] <lool> persia: actually it works, but you can't tell what name it will have
[16:59] <ndec> amitk: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/
[16:59] <lool> persia: so it's inconvenient in scripts
[16:59] <persia> amitk: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/omap/netboot/omap/
[16:59] <ogra> persia, is right as usual :)
[16:59] <persia> ogra: That's not a good reason.  The issue is that someone in cdimage (hint) needs to add the links to the template script.
[17:00] <persia> ogra: I'll dig you up a patch tomorrow if you're stuck (we can't land it until post-RC anyway)
[17:00] <amitk> ndec: looking for netboot images, not netbook ;)
[17:00] <ogra> persia, well, if i'm allowed to, i'm not sure what the status on supportability is here
[17:00] <lool> amitk: these are in the archive directly
[17:00] <persia> ogra: omap is *already* on cdimage.
[17:00] <lool> amitk: we dont copy them to cdimage anymore
[17:00] <persia> ogra: The issue is that they aren't likely to get to release
[17:00] <amitk> right, just found out lool
[17:01] <lool> amitk: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/
[17:01] <ogra> persia, i'm currently more worried about the fs_setenv bug that i cant solve
[17:01] <lool> oh right
[17:01] <ogra> i have no idea whats wrong
[17:01] <persia> ogra: Go fix that.  I'll give you a patch once the cdimage freeze lifts.
[17:01] <ogra> and that it works flawless in d-i doesnt help
[17:01] <ogra> persia, i'd love to, but i have no idea whats going on there
[17:02] <persia> amitk: Could you file a bug against ubuntu-cdimage about the missing netboot links?
[17:03] <ndec> ogra: if I want to change the bootargs in boot.scr, do I just edit the file with emacs or do I need to regenerate something?
[17:04] <asac> ndec: usually i remove the stuff from top, and then run mkimage ... again
[17:04] <asac> after editing
[17:04] <asac> that works quite well
[17:05] <plars> GrueMaster, saeed: are either of you able to reproduce the suspend/resume problems I just updated the bug with on dove?
[17:05] <GrueMaster> plars: bug #?
[17:05] <asac_> hey. had reconnect
[17:05] <plars> GrueMaster: https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/551491
[17:05] <ubot4> Launchpad bug 551491 in linux-mvl-dove (Ubuntu) "BSP update for Marvell Dove kernel LSP 5.1.0 (affects: 1) (heat: 8)" [High,In progress]
[17:06] <asac_> if something was written i didnt get it
[17:06]  * ogra had a OOM on his laptop
[17:06] <ogra> sigh
[17:06] <ogra> lucid sucks
[17:06] <asac_> ogra: hmm. i didnt hear that ;)
[17:06] <ogra> https://bugs.edge.launchpad.net/bugs/565981
[17:06] <ubot4> Launchpad bug 565981 in xorg-server (Ubuntu Lucid) (and 1 other project) "[KMS] gem objects not deallocated (affects: 15) (dups: 2) (heat: 96)" [Critical,Confirmed]
[17:07] <ogra> pitti just mailed -devel about it
[17:07] <GrueMaster> plars: What do you mean by "enable audio"
[17:07] <asac_> ouch
[17:07] <ogra> yeah
[17:07] <ogra> i have to reboot once a day and see a lot of sad faces in chromium every day
[17:08] <asac_> ogra: chromium != lucid ;)
[17:08] <ogra> asac_, so with the fw_setenv bug i doubt we can have netbook for lucid
[17:08] <asac_> (intentionally)
[17:08] <ogra> asac_, chromium is just fallout
[17:09] <ogra> in the end my whole desktop dies
[17:09] <plars> GrueMaster: unmuting the hp jack
[17:09] <plars> GrueMaster: so that audio works
[17:09] <GrueMaster> Ok, might want to clarify that in the bug report.
[17:09] <plars> GrueMaster: not sure that it's related, but I think it's about the only thing I did between the time it worked, and stopped working
[17:09] <GrueMaster> Otherwise it sounds like audio is disabled by default (it isn't).
[17:10] <plars> GrueMaster: not truly disabled, no, you just can't hear anything til you do that
[17:10] <GrueMaster> Yes, you can if you have the right hookup.
[17:11] <ogra> asac, another reconnect ?
[17:11] <GrueMaster> I have a 2 RCA-to-mini female cable for just this purpose.
[17:12] <GrueMaster> Just because the platform is designed with different audio jacks than normal desktops doesn't mean audio is disabled or not working by default.
[17:13] <GrueMaster> Babbage has a special connector for laptop speakers and defaults to that (I'm still looking into the HP jack single channel issue on it though).
[17:13] <hrw> have a nice rest of day
[17:14]  * ogra has a screwed rest of day now :( after realizing the netbook image wont work 
[17:18] <asac> ogra: no i was connected through a second irc client until i was able to get my new ip ;)
[17:18] <ogra> ah
[17:18] <plars> GrueMaster: oh, ogra resolved that this morning
[17:19] <GrueMaster> resolved what?
[17:19] <plars> GrueMaster: use the hdphone jack instead, make sure it's set to audio output stereo
[17:19] <plars> GrueMaster: on imx51, the single channel problem
[17:19] <GrueMaster> ok, I'll try it here.
[17:20] <ogra> GrueMaster, HDSET -> mono phone headset, HDPHONE -> headphones (my guess)
[17:20] <ogra> you could probably take a look in the docs though to confirm that
[17:21] <plars> GrueMaster: seems that there's no good way to get input though
[17:39] <GrueMaster> plars: Why not plug a headset into the imx51 and try it that way?  I have one here I can try.
[17:39] <GrueMaster> oops, different plug.
[17:41] <plars> GrueMaster: hmm? I'm not following.  I did try it and it worked for me
[17:43] <GrueMaster> I was referring to the input.
[17:43] <plars> GrueMaster: I tried it briefly without success, but admittedly have not had much time to spend on it yet
[17:43] <GrueMaster> If that is a headset jack, then it should be able to work with a standard phone headset (proficed the plug is the same size).
[17:44] <plars> GrueMaster: ah, no I was just trying with a normal mic
[17:44] <GrueMaster> normal mic might be wired wrong for this.
[17:51] <plars> ogra: based on your previous comments, I assume the FlashKernel errors from Ubiquity on omap are still to be expected?
[18:05] <GrueMaster> plars: I can get recording working on my babbage using the mic from my babbage 1 plugged into the internal connector.
[18:06]  * Martyn has audio working on the tegra2 .. but using a USB adapter
[18:06] <Martyn> I'll need to keep hacking away at the linux driver for the SoC based hardware
[18:06] <GrueMaster> Martyn: USB audio is a completely different driver set.
[18:07] <GrueMaster> Still alsa, but not soc audio.
[18:07] <Martyn> GrueMaster: Yep!
[18:07] <Martyn> GrueMaster: But I needed it to work temporarily :)
[18:08] <Martyn> so it was a good interim solution
[18:08] <Martyn> I nearly have the tegra2 built in audio working.. there's an issue with the buffer I'm trying to solve
[18:08] <Martyn> but I definitely have the mic input working now
[18:34] <ogra_cmpc> plars, yes and i have no idea how to fix it :( http://paste.ubuntu.com/419902/
[18:34] <ogra_cmpc> it doesnt occur in d-i installs at all
[18:35] <plars> ogra: something, probably in ubiquity, is trying to grab a huge chunk of ram it seems
[18:35] <plars> ogra: any chance we could fiddle with the compcache percentages and make it happier?
[18:35] <ogra_cmpc> plars, well, at that point there is even real swap available
[18:36] <plars> ogra_cmpc: but order 5 is 128M right?
[18:36] <plars> ogra_cmpc: that is clearly going to fail under our current setup
[18:36] <plars> no matter how much swap we have
[18:36] <ogra_cmpc> ubiquity calls swapon dirctly after partitioning
[18:37] <ogra_cmpc> we use 128M compcache, right
[18:37] <ogra_cmpc> i wonder if we need it at all now that we run in only-ubiquity mode
[18:38] <ogra_cmpc> RAM should be sufficient to get through to the installer
[18:38] <ogra_cmpc> err
[18:38] <ogra_cmpc> partitioner
[18:39] <plars> ogra: ram only? or back to 25% compcache?
[18:39] <ogra_cmpc> plars, if you want to test that you could swapoff ramzswap after partitioning on tty
[18:39] <ogra_cmpc> or even before
[18:40] <ogra_cmpc> i wonder if we probably hit a general compcache issue here
[18:40] <plars> ogra_cmpc: yeah, will give it a try.  Is swapoff enough to make it let go of that memory?
[18:40] <ogra_cmpc> rmmod probably too
[19:50] <plars> ogra_cmpc: ok, I did the swapoff and rmmod early (right after booting) and still got a couple of page_alloc failures early on, but I was able to complete the install!
[19:54] <ogra_cmpc> plars, dang ... not sure how to special case that in a nonintrusive way that slangasek accepts
[19:54] <ogra_cmpc> i'll think about it we cant do anything before RC anyway
[19:55] <plars> ogra_cmpc: I'd like to experiment a bit... I'm wondering if we could tone down the 50% to something like 35% and get away with it
[19:55] <ogra_cmpc> plars, thanks a lot for the test !
[19:55] <plars> ogra_cmpc: at the very least, we have a cumbersome workaround
[19:55] <ogra_cmpc> sure, play if you like
[19:55] <ogra_cmpc> yeah
[19:55] <ogra_cmpc> very good work !
[19:57] <plars> ogra_cmpc: I'll open a new bug against casper on this, rather than recycle the old one, unless you feel different?
[19:57] <ogra_cmpc> yeah, do that
[19:57] <plars> I think circumstances have changed enough that just tacking it on and reopening the old one would be confusing
[19:58] <ogra_cmpc> indeed
[19:58] <ogra_cmpc> though the question is if slangasek will allow it or not
[19:58] <ogra_cmpc> and i also think it might really be specific to the omap kernel
[19:59] <ogra_cmpc> i.e. .33 obviously has a new compcache implementation, there is very likely a reason for that
[20:00] <ogra_cmpc> would be intresting to see what a babbage board does in the same case if you boot with mem=256M