[08:50] <ogra_> ppisati, ddi you include the fix for bug 746137 in your last upload ?
[08:50] <ubot2> Launchpad bug 746137 in linux-ti-omap4 "Page allocation failure on Pandaboard and Beagle XM" [High,Confirmed] https://launchpad.net/bugs/746137
[08:50] <ogra_> seems QA is seeing it recently on the bamboo-feeder http://pastebin.ubuntu.com/1212016/
[09:15] <ppisati> ogra_: AFAIK there's no fix
[09:15] <ogra_> err, cooloney worked one out weeks agai
[09:16] <ogra_> *ago
[09:16] <ppisati> then i'm not aware of it
[09:16] <ppisati> i know there's a systcl to workaround it
[09:16] <ppisati> but IMO all the fixes proposed so far
[09:16] <ppisati> are not working
[09:16] <ogra_> GFP_ATOMIC vs GFP_KERNEL i think
[09:16] <ppisati> cooloney: ^
[09:16] <cooloney> ogra_: i saw patches for Panda was merged by ppisati
[09:17] <cooloney> the patch is a hack from Andy Green
[09:17] <ogra_> oh, he merged it without knowing ?
[09:17] <ogra_> haha
[09:17] <ogra_> k, as long as its in ...
[09:17] <cooloney> that's for panda, not for Beagle
[09:17] <ogra_> ah
[09:17] <ogra_> well, would be good to have it in beagle too
[09:17]  * ppisati is schizophrenic then
[09:17] <ppisati> well guys
[09:17] <ogra_> since we have no way to apply userspace hacks anymore like we did with preinstalled images
[09:18] <ppisati> but if we still have that problem even with the supposed fix
[09:18] <cooloney> ogra_: i tried a patch MingLei gave to me from upstream some maintainer.
[09:18] <ppisati> it's clearly not working
[09:18] <cooloney> ogra_: but it doesn't work.
[09:18] <ogra_> ppisati, how would you know ?
[09:18] <ogra_> your upload is in the archive but we have no new images with it yet
[09:18] <ppisati> ogra_: but it's not there for sure
[09:18] <ppisati> i mean
[09:18] <ppisati> cooloney: which patch were you referring?
[09:19] <ppisati> ogra_: in the last upload there's the video/unity flickering fix
[09:19] <ogra_> hmpf, i had the impression that was long fixed
[09:19] <ppisati> ogra_: and a rebase on origin/master (latest 3.5 stable)
[09:19] <cooloney> ppisati: a patch not in public, it is for smsc95xx usb net driver
[09:19] <ogra_> ah, if its driver specific that should work for beagle too then
[09:19] <cooloney> ppisati: the patch from Andy is in your ti-omap4, so it should be workarounded
[09:20] <ogra_> they use the same chip
[09:20] <cooloney> but for beagle it is in master.
[09:20] <ppisati> ogra_: iirc, conrad approached me weeks ago and told they have the same problem on builders
[09:20] <cooloney> the hack will touch other flavors.
[09:20] <ogra_> conrad ?
[09:20] <ppisati> ogra_: adam
[09:20] <ogra_> do you mean infinity ?
[09:20] <ppisati> yes
[09:20] <cooloney> infinity: ^^
[09:20] <ogra_> ah, conrad adam ... the evil twin of adam conrad *g*
[09:21] <ppisati> :)
[09:21] <ogra_> i dont think the builders run quantal, so thats not a surprise
[09:22] <ogra_> and they dont use preinstalled images to set them up (which would get them the fix) but use ubuntu-core with manual config or some such
[09:22] <ppisati> ogra_: yep
[09:22] <ppisati> ogra_: what i meant was that we never really fixed it
[09:22] <ogra_> s/get them the fix/get them the userspace fix/
[09:23] <ppisati> ogra_: and if we have a supposed workaround in
[09:23] <ppisati> ogra_: but we still experience it
[09:23] <ogra_> well, i lost the opportunity to work around it in userspace ...
[09:23] <ppisati> ogra_: then we should a) investigate the problem b) back out the workaround
[09:23] <ogra_> and i havent seen it in ages here in my tests
[09:24] <ogra_> so i personally had the impression it was long fixed
[09:24] <infinity> ogra_: The buildds use d-i over PXE on precise, but they have the userspace hack in puppet.
[09:24] <ogra_> until hggdh pinged me over night today
[09:24] <ppisati> infinity: and do they suffer the problem?
[09:24] <infinity> ppisati: No.
[09:24] <ppisati> uhm
[09:24] <ogra_> and funnily the saem thing is discussed on #beagle today too
[09:24] <ogra_> ppisati, the userspace hack always worked
[09:25] <infinity> ppisati: But any machine installing from an installer that doesn't put the userspace hack in place will have the issue.
[09:25] <ppisati> the userspace stuff was the sysctl config, right?
[09:25] <infinity> Right.
[09:25] <ogra_> right
[09:25] <ogra_> worst case we should just bump it at build time for certain arches
[09:25] <ogra_> in the kernel code ... if thats possible
[09:26] <ogra_> so we would just move the userspace hack into the kernel
[09:26] <ppisati> i wonder if can pass it via cmdline
[09:26] <ogra_> well you can definitely just create the sysctl.d file ... its a one liner
[09:27] <ogra_> not susre sysctl values are read from cmdline
[09:27] <ppisati> right
[09:27] <infinity> If it should always start at a certain value, and it's not, passing it on the cmdline (or sysctl) is the wrong answer.
[09:27] <infinity> The initial value should be correct.
[09:27] <infinity> I think we've been over this a few dozen times.
[09:27] <ppisati> but they are kernel variables
[09:27] <ogra_> heh, yeah
[09:27] <infinity> ppisati: Yes, it's a variable, but variables should have sane defaults.  This one clearly isn't sane for ARM.
[09:30] <ppisati> vm.min_free_kbytes = 8192
[09:30] <infinity> Anyhow, I should sleep.
[09:30] <ppisati> uhm
[09:30] <infinity> If I recall, apw was deeply involved in the last round of this conversation.
[09:30] <cooloney> ppisati: i suggest we instroduce a config option in master branch like CONFIG_VM_MIN_FREE_KBYTES
[09:30] <ppisati> sleep well
[09:30] <infinity> And he doesn't seem to be in the channel.
[09:30] <infinity> So you might want to take this to #-kernel.
[09:30] <cooloney> which should be 8192 by default for x86, powerpc
[09:31] <cooloney> and 32768 for ARM
[09:31] <ppisati> vm.min_free_kbytes = 32768
[09:31] <ppisati> on my Q/omap4
[09:31] <cooloney> and porting Andy's hacking patch to master
[09:31] <cooloney> ppisati: yeah, it should be 32768 for ARM since it was forced to be that in mm/page_alloc.c
[09:32] <ppisati> so we are "already "good"
[09:32] <ppisati> ?
[09:32] <infinity> Oh, kay, so we HAVE worked around it in the kernel?
[09:32] <cooloney> yeah, but beagle is omap3, which is master kernel
[09:32] <ogra_> on omap4, but not on omap (which uses the same driver)
[09:32] <cooloney> not on your branch,
[09:32] <infinity> Ahh, not in master.  Check.
[09:32] <ppisati> wait
[09:32] <cooloney> we need put such similar patch in master
[09:33] <infinity> Couldn't you just wrap it in #ifdef __ARM__ and commit to master?
[09:33] <ppisati> ogra_: didn't you say we hit this problem on omap4 tonight?
[09:33] <cooloney> if you put the same patch in master, it will set it to 32768 for all the flavors
[09:33] <cooloney> like x86 and powerpc
[09:33] <infinity> I guess highbank and armadaxp would pick it up too, then, but that's not world-ending.
[09:33] <ogra_> ppisati, i was notified by hggdh in #ubuntu-bugs tonight with the pastebin i gave above ... havent talked to him yet
[09:33] <infinity> cooloney: Hence why I said wrap it in an ifdef.
[09:33] <ppisati> ogra_: oh
[09:33] <infinity> cooloney: Though, obviously a CONFIG_ is better.
[09:34] <ogra_> (since he is asleep like every sane person on that american continent atm)
[09:34] <ppisati> so, even with the fix
[09:34] <ppisati> we hit the problem
[09:34] <infinity> cooloney: And the CONFIG_ change would be upstreamable even.
[09:34] <cooloney> infinity: yeah, that should be ok for just local hacking, heh
[09:34] <ogra_> ppisati, well, lets see what exactly he tested there
[09:34] <ppisati> ok
[09:34] <ogra_> i need to talk to him first
[09:34] <cooloney> infinity: i don't think we need such hacking for highbank and amadaxp
[09:34] <ppisati> ok
[09:34] <ppisati> wait a sec
[09:34] <ogra_> in any case people in #beagle are seeing it and have discussed it today
[09:35] <cooloney> because they don't use usb ethernet controller
[09:35] <infinity> cooloney: Right, hence why a CONFIG_ would be better.
[09:35] <ppisati> qait wait
[09:35] <ppisati> i just noticed one thing
[09:35] <cooloney> only beagle
[09:35] <cooloney> infinity: CONFIG_ can be set as different value for different flavor
[09:35] <infinity> ogra_: That pastebin is an ancient kernel.
[09:36] <ppisati> tight
[09:36] <ppisati> rigjt
[09:36] <ppisati> ah
[09:36] <ppisati> it's a 3.4.x
[09:36] <ogra_> i have heard many reports that people on intel have seen it too btw
[09:36] <infinity> cooloney: Yes, I know. :P
[09:36] <ppisati> we have the fix in 3.5
[09:36] <ogra_> it isnt arch specific but USB related
[09:36] <cooloney> or just use #ifdef USB_NET SMSC95XX
[09:36] <cooloney> like this kind of hacking
[09:37] <cooloney> ppisati: what's kind of fix in 3.5?
[09:44] <ppisati> 86b83747713545234c28e5347c6f0e5efb652332
[09:44] <ppisati> HACK force min_free_kbytes set by proc to min 32K to workaround smsc problems
[09:44] <ppisati> Signed-off-by: Andy Green <andy.green@linaro.org>
[09:45] <ppisati> actually even this one
[09:45] <ppisati> 89b16e837180b215b667affdd4227220827f8bb4
[09:45] <ppisati> HACK force min_free_kbytes to 32K to workaround smsc problems
[09:45] <ppisati> both are needed
[09:45] <ppisati> the second one is a safe belt
[09:45] <ppisati> the first one is the real one
[09:53] <ogra_> ppisati, did you put the LP bug number for the flickering in the changelog ? (i didnt see it in teh pull request mail)
[09:53] <ogra_> Laney, ^^^
[09:54] <cooloney> ppisati: i didn't see that patch in the real code. can you see that code in the mm/page_alloc.c?
[09:54] <cooloney> ppisati: although i can git show that patches you posted
[09:58] <ppisati> ogra_: i didn't know there was a bug opened for it
[09:59] <ogra_> bug 1045491
[09:59] <ubot2> Launchpad bug 1045491 in linux-ti-omap4 "Moving mouse messes up the desktop" [High,Confirmed] https://launchpad.net/bugs/1045491
[09:59] <ppisati> ah ok
[09:59] <ppisati> ok
[09:59] <ppisati> i'll close it manually
[10:00] <ogra_> well, let me take care
[10:00] <ogra_> i'll close it if it has been tested with the images :)
[10:02] <ogra_> (if i dont, kate will hunt me down anyway)
[11:34] <ppisati> ogra_: where is the template for preEnv.txt? or, how do i make it look as i like? or how do i make flash-kernel NOT replace its content at every run?
[11:35] <ogra_> ppisati, /etc/default/flash-kernel
[11:35] <ppisati> ogra_: ack
[12:09] <sveinse> As a part of a custom/proprietary first-boot system, I need to run a series of disk partitioning operations prior to mounting the real root. What would be preferred: a dash script with the required support tools (sfdisk, awk, grep, etc.) or to pull in python into initramfs?
[12:10] <ogra_> sveinse, have a look at the jasper-initramfs code
[12:11] <sveinse> ogra_, voila. Thanks
[12:11] <ogra_> specifically at the jasper_growroot script
[12:11]  * sveinse discoveres that the wheel has already been invented
[12:12] <ogra_> and obsoleted too :)
[12:12] <sveinse> I'm not there yet :P
[12:39] <sveinse> Any of you people the author(s) of jasper-initramfs?
[12:39] <ogra_> yes
[12:39] <sveinse> Why do you reboot after resizing root?
[12:39] <ogra_> any of me are :)
[12:40] <ogra_> because i'm a coward :)
[12:40] <ogra_> and want to make sure it actually worked before moving on with the install
[12:40] <ogra_> its not actually necessary if you are sure its all fine
[12:41] <ogra_> (i.e. if you dont have people with random SD cards as media)
[12:41] <sveinse> its just that there any isn't more you can do with a reboot compared to just continue. But I get the point
[12:42] <sveinse> Except that you know that the bootloader is still intact after altering the parttables
[12:42] <ogra_> you do test if the UUID and partitioning is still  right and if the bootloader still does the right thing on a fresh boot
[12:43] <sveinse> yup
[12:43] <ogra_> jasper_growroot also isnt the only script there ... jasper modifies other things too and sets them up
[12:43] <sveinse> i also noticed a loop around resize2fs. Doesn't it do enough in one iteration?
[12:44] <sveinse> (not that I've deciphered the sed and char logic in there)
[12:44] <ogra_> thats for plymouth
[12:45] <sveinse> ah. of course
[12:45] <ogra_> resize2fs runs through several iterations, the loop just picks up the output and dumps it to plymouth or the text console
[12:45] <ogra_> its not resize2fs itself thats gets looped over ... only the output
[12:46] <sveinse> you mean resize2fs does NOT run in loop, yes, I see that now
[12:46] <ogra_> right
[12:46] <ogra_> the while sits after the pipe
[12:48] <sveinse> and I also found some nice sysctl settings for having root on sd-cards. Are there any more goodies like this I should be aware of?
[12:49] <lilstevie> I need to start using that :p
[12:50] <lilstevie> I often get users of my transformer images complaining about it just stopping when resize2fs is running
[12:51] <ogra_> sveinse, the zram-conf package is helpful if your kernel supports it (speeds up swapping a lot)
[12:51] <ogra_> and here on my ac100 i just experiment with a journal-less ext4 ... thats classes faster than any FS i have tried yet
[12:52] <ogra_> though with that you should force an fsck on every boot
[12:53] <ogra_> ogra@horus:~$ cat /etc/security/limits.d/90-stack.conf
[12:53] <ogra_> * soft stack 256
[12:53] <ogra_> thats also pretty helpful when being low on ram
[12:54] <lilstevie> what is required for zram anyway
[12:54] <ogra_> (default is 8k per thread stack, makes your apps use less ram (and since its soft they can just ask for more if needed))
[12:54] <ogra_> lilstevie, that you enable it in your kernel config
[12:54] <lilstevie> I have no idea if I included the right bits
[12:55] <lilstevie> :p
[12:55] <ogra_> i think there is only one option (or probably two)
[12:55] <lilstevie> config_cramfs?
[12:56] <lilstevie> I guess I should just try it lol
[12:56] <ogra_> no, thats a filesystem
[12:56] <lilstevie> ah right
[12:56] <ogra_> search for zram
[12:57] <ogra_> (hit / in menuconfig)
[12:57] <lilstevie> yeah I know how to search :p
[12:58] <lilstevie> ok yeah CONFIG_ZRAM
[12:58] <lilstevie> and it is enabled
[12:58] <ogra_> great
[13:00] <lilstevie> I have double the ram of the ac100, but IMO 1GB is far from enough
[13:02] <ogra_> yeah, imho zram should become a default as staging swap
[13:03] <ogra_> so that you first swap into compressed ram before actually writing to disk
[13:03] <lilstevie> yeah
[13:03] <lilstevie> I will have to give it a go, see how much of a performance increase it gets
[13:05] <ogra_> you will only note it when swapping
[13:05] <lilstevie> so the moment I open chromium then :p
[13:06] <ogra_> yeah, firefox uses lots less ram in its recent versions ...
[13:26] <sveinse> What's the deal with CHS geometry on omap3 and bootloader? I haven't been able to find any other combination other than H=255, S=63 that works. But I see H=128, S=32 is used in jasper
[13:26] <sveinse> so I guess that also works
[13:26] <ogra_> the ROM needs to find the first stage loader at a certain point on a vfat to boot
[13:27] <sveinse> (I have to admit I'm confused about CHS vs LBA and how they interact)
[13:27] <ogra_> thats omap specific
[13:28] <ogra_> i doubt you need CHS on tegra
[13:30] <lilstevie> ogra_, tegra scans until it finds the bct
[13:30] <ogra_> right
[13:30] <sveinse> from what I understand, there partition table contains both CHS and LBA fields. And Linux uses only LBA, right.
[13:31] <sveinse> So given that you're able to boot, when sfdisk complains about partitions not on cylinder boundaries is just a warning, but it does not affect anything
[13:49] <sveinse> ogra_, A proposal: You dont strictly need to use fdisk to determine the size of the disk. sfdisk can do that as well. So you can spare a binary in initramfs
[13:49] <ogra_> sveinse, well, jasper is pretty much dead beef
[13:50] <sveinse> ok, just saying
[13:50] <ogra_> we only keep it in the archive in case we will actually spin preinstalleds once again
[13:50] <ogra_> over time it will vanish from the arhcive though, i wont put any work into it
[13:51] <ogra_> and yeah, i know that sfdisk can do this
[14:40]  * ogra_ looks at bug 1044709 and wonders what got infinity the honor to be the new unity slave
[14:40] <ubot2> Launchpad bug 1044709 in unity/6.0 "unity-6.4.0 from quantal-proposed crashed with SIGSEGV on omap4" [Critical,Fix committed] https://launchpad.net/bugs/1044709
[14:41] <ogra_> oh you actually commited that to their tree
[20:40] <jimerickson> omap4+armhf: it works. enough said.
[20:44] <GrueMaster> jimerickson: Erm, when didn't it?
[20:54] <jimerickson> was have some flashing screen problems with the last kernel. but this latest update has resolved it.
[21:03] <GrueMaster> Ah.
[21:14] <Deformati> Anyone here know about performance counters?
[21:46] <GrueMaster> I do, sort of.
[21:46] <GrueMaster> At least from the Pentium Pro days.
[22:54] <Deformati> GrueMaster, For some reason on omap4 devices the performance counters are disabled and there doesn't seem to be documentation for enabling them.
[22:54] <Deformati> So I suppose pentium pro isn't relevant.
[22:55] <GrueMaster> Yea, propably not.  :P
[22:55] <GrueMaster> You might ask on #pandaboard though.  They can probably help, if it is harder than simply rebuilding the kernel.
[23:00] <GrueMaster> It should be fairly straight-forward though.  Looks like it can be done by downloading the kernel source package for the kernel you are using, then modify the config to enable perf counters.
[23:00] <GrueMaster> And rebuild.
[23:00] <GrueMaster> Documentation is at http://help.ubuntu.com/community/Kernel/Compile
[23:27] <Deformati> GrueMaster, I tried that.
[23:28] <Deformati> There is a bug report on launchpad.
[23:28] <GrueMaster> And the new custom kernel didn't work?
[23:28] <Deformati> The existing kernel has it enabled.
[23:28] <GrueMaster> ah, ok.
[23:29] <Deformati> But warmcat says on the launchpad bug report that it is intentionally disabled, i cannot find what they disabled or where.
[23:29] <Deformati> I just get errors every time I try to use the PMU.
[23:32] <GrueMaster> Sounds like possibly a #linaro or #pandaboard issue.
[23:32] <Deformati> Ok.
[23:33] <GrueMaster> I seem to remember some discussion on this a while back (like 11.10 timeframe).