**** BEGIN LOGGING AT Mon Jul 16 02:59:58 2012
Jul 16 13:08:04 <ogra_> bug 1014139
Jul 16 13:08:06 <ubot2> Launchpad bug 1014139 in flash-kernel "flash-kernel fails to umount flash device after writing" [High,Fix released] https://launchpad.net/bugs/1014139
Jul 16 14:31:38 <janimo> ogra_, in nvtegra-graphics we probably should use arm-linux-gnueabihf suffixes for the alternative symlinks just to be in sync with the fact they're now armhf
Jul 16 14:31:54 <ogra_> feel free to port it :)
Jul 16 14:32:23 <ogra_> though i dont think the x86 version actually uses much of multiarch
Jul 16 14:32:33 <janimo> can be included in the next upload I guess
Jul 16 14:32:50 <ogra_> great, i have the final release of v15 here on disk
Jul 16 14:32:53 <janimo> nvidia devzone sitll down
Jul 16 14:33:02 <janimo> oh the one from july 6?
Jul 16 14:33:22 <janimo> can you put it somewhere if you are not packaginging it? :)
Jul 16 14:33:32 <ogra_> -rw-rw-r--  1 ogra ogra 6,8M Jul 10 10:19 ventana_nv-tegra_base_R15.1.0_armhf.tbz2
Jul 16 14:33:39 <ogra_> jul 10th, but yes
Jul 16 14:33:43 <janimo> ok
Jul 16 14:33:53 <janimo> just before their site was shut down
Jul 16 14:34:11 <janimo> although I see the relnotes mentioning they still have arterfacts with gtk, on resume, etc
Jul 16 14:34:13 <ogra_> yup :)
Jul 16 14:34:14 <lilstevie> ogra_, have you checked if the ventana and cardhu versions differ at all
Jul 16 14:34:28 <lilstevie> yeah, they are ok though
Jul 16 14:34:38 <ogra_> lilstevie, i havent checked anything yet, banging my head against an image problem currently
Jul 16 14:34:54 <lilstevie> although I have noticed if you aren't using the -r15-rc tag you will have problems
Jul 16 14:34:57 <ogra_> i just grabbed the tarball in case the site might go down ;)
Jul 16 14:35:02 <lilstevie> ogra_, ah
Jul 16 14:35:05 <janimo> ogra_, is the image problem due to needing to pass console= or due to initramfs size limitation?
Jul 16 14:35:22 <lilstevie> the downloads are still available via their direct links fwiw
Jul 16 14:35:38 <ogra_> janimo, well, console= is in now, so that shouldnt cause issues, currently it does with "no init found" i assume thats the size issue
Jul 16 14:35:41 <janimo> lilstevie, I googled in vain for such links? Do you have them ? :)
Jul 16 14:36:13 <ogra_> http://people.canonical.com/~ogra/tegra/ventana_nv-tegra_base_R15.1.0_armhf.tbz2
Jul 16 14:36:19 <ogra_> still uploading
Jul 16 14:36:20 <janimo> lilstevie, r15-rc you mean tag in nvidia kernel git repo?
Jul 16 14:36:26 <lilstevie> yes
Jul 16 14:36:49 <janimo> lilstevie, what do they do in the kernel that is so intertwined with the graphics drivers?
Jul 16 14:36:54 <lilstevie> Couldn't open /sys/bus/nvhost/devices/host1x/syncpt/22/max
Jul 16 14:37:01 <ogra_> janimo, done, feel free to pull
Jul 16 14:37:06 <janimo> ogra_, thanks
Jul 16 14:37:49 <lilstevie> janimo,  the fact that the userspace driver has to rely on kernel interface
Jul 16 14:38:01 <janimo> lilstevie, but what specifically?
Jul 16 14:38:12 <lilstevie> a whole heap of stuff
Jul 16 14:38:15 <janimo> what kernel APIs/ABIs they change?
Jul 16 14:38:24 <janimo> anything standard or nvidia specific drivers only
Jul 16 14:38:29 <lilstevie> nvidia specific
Jul 16 14:38:34 <janimo> so dev/nv* stuff?
Jul 16 14:38:36 <janimo> ok
Jul 16 14:38:50 <lilstevie> sys/bus/nv* stuff
Jul 16 14:38:58 <lilstevie> the error with es2gears is Couldn't open /sys/bus/nvhost/devices/host1x/syncpt/22/max
Jul 16 14:39:17 <janimo> I am sure for the ac100 we used kernels which were not the exact versions nvidia recommended/shipped with the L4T but it still worked more or less
Jul 16 14:39:19 <lilstevie> and checking the path syncpt doesn't exist
Jul 16 14:39:42 <janimo> lilstevie, so right now using 15 final and the git tag you mentioned should be all ok?
Jul 16 14:39:51 <lilstevie> should be
Jul 16 14:40:11 <lilstevie> need to sync to that tag myself
Jul 16 14:40:51 * ogra_ didnt have any issues with our kernel and the v15beta
Jul 16 14:41:08 <ogra_> did they really change so much between beta and final ?
Jul 16 14:41:16 <lilstevie> they added a whole heap of stuff
Jul 16 14:41:30 <lilstevie> for use of HDMI fcbon
Jul 16 14:41:33 <lilstevie> fbcon*
Jul 16 14:42:01 <lilstevie> ogra_, I didn't think there was an issue until I tried es2gears
Jul 16 14:42:23 <ogra_> well, es2gears worked on beta with our 3.1 kernel
Jul 16 14:42:35 <lilstevie> yeah es2gears worked with beta here too
Jul 16 14:42:36 <ogra_> as well as unity and compiz
Jul 16 14:42:41 <lilstevie> it is with the release that didn't
Jul 16 14:42:46 <lilstevie> ok I have a unity issue
Jul 16 14:42:54 <ogra_> transparency ?
Jul 16 14:43:04 <lilstevie> menubar is gone
Jul 16 14:43:06 <ogra_> thats known and i guess a driver issue
Jul 16 14:43:13 <lilstevie> and the top bar
Jul 16 14:43:14 <ogra_> its there, just transparent
Jul 16 14:43:18 <lilstevie> dash home and hud
Jul 16 14:43:19 <lilstevie> yeah
Jul 16 14:43:24 <ogra_> you can click on items, open menus etc
Jul 16 14:43:28 <lilstevie> sorry, yeah they are there, but transparent
Jul 16 14:43:34 <ogra_> yeah, very likely a driver issue
Jul 16 14:43:41 <ogra_> since it works on PVR
Jul 16 14:43:51 <lilstevie> but not being able to see dash home is a bit of an issue :p
Jul 16 14:44:12 <ogra_> pfft ... it trains your fantasy
Jul 16 14:44:18 <lilstevie> lol
Jul 16 14:45:27 <lilstevie> in any case, makes accelerated unity unusable
Jul 16 14:45:46 <ogra_> right, currently: use a panda for that :)
Jul 16 14:46:19 <lilstevie> yes, well I don't have one of those
Jul 16 14:46:29 <lilstevie> just 3 tegra powered devices :p
Jul 16 14:46:50 <lilstevie> I figured it was a driver issue though, cause the same happens on my trimslice
Jul 16 14:46:50 <ogra_> so pray that nvidia fixes their driver some day :)
Jul 16 14:47:00 <lilstevie> lol
Jul 16 14:47:04 <ogra_> i'm pretty sure there is a function missing in their GLES implementation
Jul 16 14:47:24 <lilstevie> so someone needs to log a bug
Jul 16 14:47:29 <ogra_> i heard unity works on mali too ...
Jul 16 14:47:39 <ogra_> so PVR and mali should be fine ...
Jul 16 14:48:06 <ogra_> not sure about the amd chips that freescale uses on their boards ...
Jul 16 14:48:17 <ogra_> janimo, did you ever test 3D stuff on the mx5 ?
Jul 16 14:48:43 <janimo> ogra_, not besided the factory SD card, which has nicely working 3D
Jul 16 14:48:50 <ogra_> ah
Jul 16 14:48:55 <janimo> I think I had the NDA'd proprietary 3d libs too
Jul 16 14:49:04 <janimo> but I can't recall if I could make them work
Jul 16 14:49:06 <ogra_> would be intresting to know if unity works there ... but i guess thats to much effort
Jul 16 14:49:12 <janimo> or maybe I did not even have them
Jul 16 14:49:31 <janimo> of little use for users if the libs are not freely available
Jul 16 14:49:33 <lilstevie> yeah, so we need to figure out what is missing from the nvidia ones, then pester them for 2 years until they fix it
Jul 16 14:50:17 <ogra_> in which case we will have switched to wayland and have to start over bugging them about the same issue in a new driver
Jul 16 14:50:24 <ogra_> :)
Jul 16 14:51:06 <janimo> ogra_, lilstevie above disussion makes it sound we do not want to upgrade to l4t 15 final :)
Jul 16 14:51:23 * ogra_ prefers that we do 
Jul 16 14:51:44 <lilstevie> janimo, why?
Jul 16 14:51:59 <ogra_> at least to get rid of the CSS bugs etc ... telling people to switch to unitty-2d isnt as bad as having broken screens
Jul 16 14:52:18 <janimo> lilstevie, regressions due to our kernel not being in sycn with what l4t expects
Jul 16 14:52:55 <lilstevie> janimo, there is no real regressions that you notice, so far I have only noticed an issue with es2gears and es2tri
Jul 16 14:53:05 <lilstevie> and the solution there is to not be lazy and just update the kernel
Jul 16 14:53:58 <janimo> lilstevie, well yes, we should update them more or less in sync
Jul 16 14:54:28 <janimo> maybe marvin24 rebases on the new kernel soon :)
Jul 16 14:54:57 <lilstevie> what does marvin24 have to do with it, he isn't even involved in the kernel that I use on the tfx01
Jul 16 14:55:24 <ogra_> but we use that kernel :)
Jul 16 14:55:54 <janimo> lilstevie, we use his kernel for ac100 in ubuntu
Jul 16 14:56:12 <janimo> lilstevie, but feel free to maintain a more proper tegra kernel in Ubuntu :)
Jul 16 14:56:12 <lilstevie> heh
Jul 16 14:56:27 <lilstevie> janimo, infinity and I have discussed this a few times
Jul 16 14:56:33 <janimo> noone would mind if it booted both ac100 and tf
Jul 16 14:56:36 <janimo> I know.
Jul 16 14:57:09 <lilstevie> it is a nightmare due to a bunch of OEMs using the same mtype
Jul 16 14:58:47 <janimo> lilstevie, well in a year we'll have DT tegra trees in Ubuntu, until then we try to use hacks and external kernels :)
Jul 16 14:59:13 <lilstevie> janimo, but yet we won't have DT bootloaders for all devices
Jul 16 14:59:14 <ogra_> what ? a year ?!?
Jul 16 14:59:30 <lilstevie> the 3.1 kernel supports DT fwiw
Jul 16 14:59:36 <lilstevie> the nv-tegra one
Jul 16 14:59:38 <janimo> The tegra-l4t-r15-rc tag seems to have the last commit in May. Not extremely recent
Jul 16 15:00:01 <janimo> lilstevie, well full support as in actually working and replacing the current board specific code
Jul 16 15:00:17 <lilstevie> again, still won't have it for every device
Jul 16 15:00:26 <janimo> ogra_, maybe in a year mainline kernel will have all tegra stuff merged and working
Jul 16 15:00:33 <ogra_> janimo, ah
Jul 16 15:00:35 <janimo> lilstevie, no need for every device
Jul 16 15:00:37 <marvin24> janimo: the kernel in my branch is based on the latest nv code already, will test the new driver later on
Jul 16 15:00:40 <lilstevie> I mean it was only today that it even became safe to test alternate bootloaders on the tf201
Jul 16 15:00:41 <janimo> ans popular ones will be easier to add than now
Jul 16 15:01:42 <janimo> marvin24, indeed I hope it is not too complicated. Did you base it on tegra-l4t-r15-beta ?
Jul 16 15:01:44 <marvin24> lilstevie: did you got u-boot and 3.1 kernel running?
Jul 16 15:01:53 <janimo> if you could git push --tags it may be easier to guess :)
Jul 16 15:01:59 <marvin24> janimo: no, rel-15r7
Jul 16 15:02:00 <lilstevie> marvin24, u-boot no
Jul 16 15:02:05 <lilstevie> Linux steven-laptop 3.1.10-1000-tegra #0 SMP PREEMPT Thu Jul 12 01:26:55 EST 2012 armv7l armv7l armv7l GNU/Linux
Jul 16 15:02:10 <lilstevie> kernel yes
Jul 16 15:02:12 <lilstevie> :p
Jul 16 15:02:31 <lilstevie> but we aren't using the r15-rc tag yet
Jul 16 15:02:47 <lilstevie> also rel-15r7 and r15-rc differ
Jul 16 15:02:56 <janimo> marvin24, ah indeed, the branch. Confusing branch and tag names all the time
Jul 16 15:02:57 <marvin24> well, I fact I used the tegra-15r7.1-android-4.0 tag
Jul 16 15:03:25 <marvin24> maybe I should also start to tag ...
Jul 16 15:04:01 <lilstevie> I haven't seen the r15 hdmi code in 15r7
Jul 16 15:06:23 <ogra_> ok, todays image still dies with "no init found" ... sadly i cant get any more info out of that kernel
Jul 16 15:06:35 <ogra_> even dropping quiet and spalsh doesnt print any more stuff
Jul 16 15:06:49 * ogra_ guesses thats still the console= issue
Jul 16 15:07:21 <janimo> lilstevie, you're on transformer prime?
Jul 16 15:09:16 <janimo> ogra_, is the initrd from the current bootimg causing the issue? I'll try debugging it with locally built zImages
Jul 16 15:09:31 <janimo> just need a good (broken) initrd
Jul 16 15:09:33 <lilstevie> janimo, of course
Jul 16 15:11:28 <ogra_> janimo, http://cdimage.ubuntu.com/daily-preinstalled/20120716/quantal-preinstalled-desktop-armhf+ac100.bootimg
Jul 16 15:12:04 <ogra_> abootimg -x  gets you the initrd from it
Jul 16 15:12:41 <ogra_> btw, is there any reason why we use tty1 not tty0 ?
Jul 16 15:15:01 <lilstevie> ogra_, working around the old console bug
Jul 16 15:15:39 <ogra_> lilstevie, right, by why tty1 (which forces you into a black screen) instead of tty0 ?
Jul 16 15:15:53 <janimo> ogra_, ok, flashed and got the bug. I'll have a look and see if I find the reason
Jul 16 15:16:15 <ogra_> janimo, cool, thanks, i will aslo try to experiment with different and smaller initrds
Jul 16 15:17:56 * ogra_ switches the default to tty0
Jul 16 15:18:21 <lilstevie> ogra_, the 2.6.39 kernel needed it afaik
Jul 16 15:18:24 <lilstevie> to show the console
Jul 16 15:18:32 <lilstevie> it is an old bug anyway
Jul 16 15:18:33 <ogra_> we never used it
Jul 16 15:18:37 <lilstevie> no longer present
Jul 16 15:18:38 <ogra_> its not
Jul 16 15:18:39 <lilstevie> we did
Jul 16 15:18:44 <ogra_> its a brandnew bug with 3.1
Jul 16 15:18:50 <lilstevie> oh hm
Jul 16 15:18:52 <ogra_> (for ac100 that is)
Jul 16 15:18:58 <lilstevie> wait, the plymouth bug
Jul 16 15:19:03 <ogra_> no
Jul 16 15:19:09 <lilstevie> or one where the console doesn't show
Jul 16 15:19:11 <ogra_> plymouth is a different issue
Jul 16 15:19:23 <ogra_> right, console doesnt show regardless of plymouth
Jul 16 15:19:38 <ogra_> unless you set console=tty*
Jul 16 15:19:45 <lilstevie> ok, console not showing is an old bug that only affected .39 here
Jul 16 15:19:47 <ogra_> and we defaulted to tty1 ...
Jul 16 15:19:55 <lilstevie> tty0 works just fine here
Jul 16 15:19:58 <ogra_> right
Jul 16 15:20:11 <ogra_> and you actually get kernel messages if you use tty0
Jul 16 15:20:13 <ogra_> ;)
Jul 16 15:20:15 <lilstevie> yes
Jul 16 15:20:22 <ogra_> (instead of tty1)
Jul 16 15:20:28 <lilstevie> yes
Jul 16 15:20:50 <ogra_> all workarounds and howtos for ac100 i have seen yet talk about tty1 though ...
Jul 16 15:21:08 <lilstevie> hm
Jul 16 15:24:58 <lilstevie> volume is killing me :/
Jul 16 15:25:07 <lilstevie> I have no volume control on the prime
Jul 16 15:25:13 <lilstevie> either sound is on, or muted
Jul 16 15:27:25 <scientes> who runs the armel buildds?
Jul 16 15:27:55 <scientes> My package needs a newer kernel for 8 byte atomics on armel, which apparently have been recently added to gcc, which my configure script picked up
Jul 16 15:28:01 <lilstevie> people use armel builds?
Jul 16 15:28:24 <scientes> doesn't infinity run those?
Jul 16 15:29:10 <ogra_> the canonical IS team runs all  buildds
Jul 16 15:29:20 <ogra_> (no matter what arch)
Jul 16 15:30:06 <scientes> otherwise i can switch it back to the last version where it actually test ran the binary
Jul 16 15:30:18 <scientes> but i moved to just link testing so that the package can be cross-built
Jul 16 15:30:33 <janimo> ogra_, progress
Jul 16 15:30:53 <janimo> repackaged the same initramfs using lzma and it boldly boots into the no tarball found initramfs
Jul 16 15:31:13 <janimo> lz packed size is : 2049358
Jul 16 15:31:39 <janimo> quite under the 2M limit
Jul 16 15:32:05 <janimo> so we should default to lzma initramfs's like the rest of ubuntu does - or to xc if that is used (I forgot which was the latest)
Jul 16 15:32:41 <janimo> although weird my x86 ones in /boot seem to be gzip compressed
Jul 16 15:32:50 <janimo> either way, we should try ac100 builds with lzma
Jul 16 15:34:03 <ogra_> will check how hard it is to switch it (iirc i already ship a specific initramfs-tools.conf)
Jul 16 15:35:46 <ogra_> ah, sad, thats only the in-initrd config
Jul 16 15:39:34 <ogra_> fix uploaded :)
Jul 16 15:40:21 <ogra_> lets see if that works even if not done manually :)
Jul 16 15:40:24 <scientes> what version of gcc do i need for those 8 byte atomics on armv5? (i'm just trying to figure out the kernel version)
Jul 16 15:40:32 <scientes> cause debian unstable gcc doesn't have it
Jul 16 15:40:39 <scientes> *wheezy
Jul 16 15:41:00 <ogra_> better ask in #linaro as they maintain the toolchain
Jul 16 15:41:06 <scientes> anyways, my package needs a newer kernel on the buildds
Jul 16 15:41:20 <scientes> to match the toolchain, for armel, not armv7
Jul 16 15:41:20 <ogra_> how new ?
Jul 16 15:41:27 <scientes> for the test suite
Jul 16 15:41:38 <ogra_> well, armel isnt actually supported by ubuntu atm
Jul 16 15:41:44 <scientes> ogra_, i was trying to figure out, but my gcc doesn't have the feature that the ubuntu toolchain does
Jul 16 15:41:55 <scientes> (8 byte atomic operations for armel)
Jul 16 15:42:14 <ogra_> we left it in place since there is a 1% chance that we will keep it in 12.10 ... but even that 1% shrinks with every day of the release cycle
Jul 16 15:42:32 <scientes> well do you know what kernels debian uses on buildds?
Jul 16 15:42:38 <ogra_> no idea
Jul 16 15:42:43 <scientes> cause as soon as they upgrade gcc i will end up with same problem there
Jul 16 15:42:45 <ogra_> i dont even know what HW they have
Jul 16 15:43:02 <scientes> they are using real armv5 hardware for the armel port
Jul 16 15:43:05 <ogra_> unstable should have the same gcc we use in ubuntu though
Jul 16 15:43:24 <scientes> checking for 8 byte atomic operations... yes
Jul 16 15:43:25 <ogra_> right, we dont have or support any armv5 hardware at all anymore
Jul 16 15:43:31 <scientes> I get no, using wheezy toolchain
Jul 16 15:43:48 <ogra_> wheezy != unstable :)
Jul 16 15:44:10 <scientes> well i didn't downgrade, it was unstable as of 2 weeks ago
Jul 16 15:44:12 <ogra_> anyway, targeting armel with ubuntu is probably wasted effort
Jul 16 15:44:23 <scientes> so after the debian import freee
Jul 16 15:44:33 <ogra_> did debian rename sid ?
Jul 16 15:44:43 <ogra_> to me sid == unstable ...
Jul 16 15:45:02 <scientes> ogra_, i'm pretty sure ubuntu uses their own toolchain
Jul 16 15:45:05 <scientes> from linaro
Jul 16 15:45:16 <scientes> instead of FSF/sourceware
Jul 16 15:45:27 <ogra_> scientes, well, i'm pretty sure our toolchain gets uploaded to debian and then synced from there
Jul 16 15:45:28 <scientes> at least for arm
Jul 16 15:45:40 <ogra_> since several releases now
Jul 16 15:45:44 <scientes> ahh that sounds sensible too
Jul 16 15:45:58 <scientes> cuase the docs say that 64-bit atomics arn't on arm
Jul 16 15:46:01 <scientes> but apparently they are
Jul 16 15:46:05 <ogra_> (given the maintainer is the same in linaro, ubuntu and debian)
Jul 16 15:46:11 <scientes> and i googled the kernel patches
Jul 16 15:46:49 <scientes> its good for performance of the package
Jul 16 15:47:18 <scientes> ohhh!, you guys switched to gcc-4.7
Jul 16 15:47:25 <ogra_> yes
Jul 16 15:47:32 <scientes> debian is still on gcc4.6 except for x86 and amd64
Jul 16 15:47:52 <ogra_> well, unstable should be on 4.7 too
Jul 16 15:48:10 <ogra_> i'm pretty sure doko uploads to both distros at the same time
Jul 16 15:48:14 <scientes> probably wont change until after wheezy is released
Jul 16 15:48:41 <ogra_> but anyway, armel amd especially pre- armv7 is dead beef on ubuntu
Jul 16 15:48:48 <ogra_> s/amd/and/
Jul 16 15:49:08 <scientes> ok, so i wont care the test dont run, ergo it doesn't build
Jul 16 15:49:22 <scientes> and check out debian setup
Jul 16 15:49:26 <ogra_> its very  likely that armel will be removed from the archive by feature freeze
Jul 16 15:49:48 <ogra_> unless someone steps up and pays for it
Jul 16 15:54:46 <scientes> thats ok for me, debian works fine
Jul 16 15:57:11 <ogra_> janimo, do you know from the top of your head if we have xz initrd handling enabled in the ac100 kernel ?
Jul 16 15:57:45 <ogra_> seems the consensus is to not use lzma
Jul 16 15:57:57 <scientes> ogra_, you mean lmza2 (xz)
Jul 16 15:58:25 <scientes> ogra_, its actually broken in linux 3.5
Jul 16 15:58:28 <scientes> xz is
Jul 16 15:58:35 <ogra_> we only have 3.1 for ac100
Jul 16 15:58:37 <scientes> due to merge bug
Jul 16 15:58:41 <scientes> ahh lzma works then
Jul 16 15:58:44 <scientes> but its slow
Jul 16 15:58:48 <scientes> gzip is the fastest
Jul 16 15:58:51 <ogra_> yes, but thats not the preferred method
Jul 16 15:59:01 <ogra_> i was asked to switch to xz
Jul 16 15:59:12 <scientes> lzma also have VERY high memory to compress requirements
Jul 16 15:59:14 <ogra_> i just dont know if the current ac100 kernel supports it
Jul 16 15:59:18 <scientes> ogra_, well fix the 3.5 bug then
Jul 16 15:59:27 <ogra_> as i said, we only use 3.1
Jul 16 15:59:29 <scientes> xz was merged in 3.5, but its broken
Jul 16 15:59:47 <scientes> i reported it, but nobody cared to fix it
Jul 16 16:06:25 <ogra_> janimo, i still get stack-protector kernel errors here :(
Jul 16 16:06:49 <ogra_> no matter if i use xz or lzma
Jul 16 16:16:37 <ogra_> grmbl
Jul 16 16:16:48 <ogra_> still corrupted kernel stak :(
Jul 16 16:16:53 <ogra_> *stack
Jul 16 16:17:24 * ogra_ hates kernels
Jul 16 16:17:31 <ogra_> why cant we live without them !
Jul 16 16:17:57 <cooloney> ogra_: oh, come on
Jul 16 16:18:11 <ogra_> cooloney, they always cause problems !
Jul 16 16:18:18 <ynezz> use heap!
Jul 16 16:18:31 <janimo> ogra_, sorry, was away. I used lz and it worked with the stock kernel in the bootimg
Jul 16 16:18:35 <janimo> so not xc
Jul 16 16:18:44 <ogra_> janimo, right, i tried both
Jul 16 16:18:49 <ogra_> neither works
Jul 16 16:18:54 <janimo> weird
Jul 16 16:19:00 <janimo> I just repacked the initrd there
Jul 16 16:19:05 <janimo> what sized did you get?
Jul 16 16:19:06 <ogra_> did you change anything wrt config of the bootimg ?
Jul 16 16:19:22 <ogra_> -rw-rw-r-- 1 ogra ogra 2052736 Jul 16 18:04 initrd.img
Jul 16 16:19:38 <ogra_> thats my lzma packed one
Jul 16 16:20:08 <janimo> close enough, mine was almost the same
Jul 16 16:20:10 <ogra_> oh, wait, did you cpio it or just unzip and then lzma ?
Jul 16 16:20:25 * ogra_ actually unpacked his
Jul 16 16:20:28 <janimo> cpio too I think
Jul 16 16:20:33 <ogra_> k
Jul 16 16:20:38 <janimo> I have two unpack repack scripts
Jul 16 16:20:59 <janimo> $CAT $initrd | ( cd $ramdisk; cpio -i )
Jul 16 16:21:23 <ogra_> well, in any case i always get "stack-protector: Kernel stack is corrupted in: c06a594c"
Jul 16 16:21:33 <janimo> ( cd $ramdisk; find | sort | cpio --quiet -o -H newc ) | lzma > $initrd
Jul 16 16:21:36 <janimo> so unpack and pack
Jul 16 16:21:49 <ogra_> yeah, pretty much the same i did here
Jul 16 16:21:59 <janimo> I only saw uncompress error with the original img, which then obviously turned into init not found
Jul 16 16:22:04 <ogra_> just mnot piped together ... but that shouldnt matter
Jul 16 16:22:26 <janimo> I did not pipe them either
Jul 16 16:22:33 <janimo> I mean not the unpack to the pack
Jul 16 16:22:43 <ogra_> nah, indeed
Jul 16 16:23:00 <ogra_> i mean i manually unzipped, manuall ran cpio .. etc
Jul 16 16:23:37 <ogra_> janimo, any changes to the bootimg.cfg ?
Jul 16 16:23:49 <ogra_> or do you ise the default one from the bootimg file ?
Jul 16 16:24:15 <janimo> cmdline = mem=512M@0 tegrapart=recovery:300:a00:800,boot:d00:1000:800,mbr:1d00:200:800 console=tty1 root=/dev/mmcblk0p7
Jul 16 16:24:25 <janimo> just removed the quiet splash loglevel stuff
Jul 16 16:24:27 <janimo> to get more info
Jul 16 16:24:47 <ogra_> right, looks like the default one
Jul 16 16:25:13 <janimo> if that makes the difference maybe calling splash causes the issue
Jul 16 16:25:27 <ogra_> i dont have quiet and splash here
Jul 16 16:25:37 <janimo> so similar
Jul 16 16:25:53 <ogra_> right
Jul 16 16:25:58 <janimo> maybe your unit has a hw issue?
Jul 16 16:26:07 <ogra_> well, precise works fine
Jul 16 16:26:15 <ogra_> so i doubt that
Jul 16 16:26:55 <janimo> http://startx.ro/~jani/o.img
Jul 16 16:26:59 <janimo> this is what works for me
Jul 16 16:27:23 * ogra_ pulls and tests
Jul 16 16:29:08 <janimo> but it cannot find the tarball on the usb stick
Jul 16 16:29:34 <ogra_> bah ! why does that boot
Jul 16 16:30:33 <ogra_> janimo, yeah. looks like a live-build issue, the installer.md5 file has a wrong name
Jul 16 16:31:13 <ogra_> janimo, oh !
Jul 16 16:31:32 <ogra_> the kernel misses cp437, it cant mount
Jul 16 16:31:39 <ogra_> (needed for vfat)
Jul 16 16:32:08 <janimo> indeed, that's what I saw
Jul 16 16:32:14 <janimo> I wonder if I dropped that last time
Jul 16 16:32:17 <ogra_> kernel issue then :)
Jul 16 16:32:19 <janimo> so going to add that back
Jul 16 16:32:23 <ogra_> thx
Jul 16 16:32:24 <janimo> :)
Jul 16 16:32:35 <janimo> so the initrd is now packed with lz? nice
Jul 16 16:32:38 <ogra_> it still bothers me that i dont know why my initrd doesnt work
Jul 16 16:32:54 <ogra_> yeah, we're the only ones being that inoovative :)
Jul 16 16:33:12 <janimo> put the current bootimg that does not boot somewhere, I'll try that too
Jul 16 16:33:28 <ogra_> seems lz was several times discussed ... but using it breaks rsyncability
Jul 16 16:34:49 <janimo> ogra_, lz for initrd or the whole squashfs?
Jul 16 16:35:14 <janimo> I know squashfs/lz was discussed a lot. Not even sure what is used now for squashfs
Jul 16 16:35:17 <ogra_> well, i asked about initrd in -devel
Jul 16 16:36:39 <ogra_> janimo, http://people.canonical.com/~ogra/tegra/quantal-preinstalled-desktop-armhf+ac100.bootimg
Jul 16 16:37:05 <janimo> ogra_, just read devel backlog
Jul 16 16:37:26 <janimo> it was not clear from Colin's answer that he referred to initramfs and not the whole live image
Jul 16 16:37:43 <janimo> anyway. for our case as you said lack of rsyncability is not an issue
Jul 16 16:38:08 <ogra_> yes, bootimg isnt even offered via zsync/rsync i think
Jul 16 16:38:27 <ogra_> and its small enough that even if it would be, pulling it as a whole isnt that bad
Jul 16 16:38:45 <ogra_> its only 8M after all
Jul 16 16:38:58 <scientes> ok it was added in 2.6.30---its just that its only supported on armv6k+
Jul 16 16:39:16 <scientes> i have no idea how it manages to fail on your modern hardware...
Jul 16 16:42:04 <janimo> ogra_, nothing changed in the configs AFAICT 437 is there in the configs
Jul 16 16:42:26 * ogra_ scratches head
Jul 16 16:43:24 <janimo> ogra_, although there's no nls/*ko in lib/modules in the initramfs
Jul 16 16:43:47 <janimo> kernel/fs/nls is nonexistent
Jul 16 16:44:01 <janimo> I wonder if earlier initrds had that
Jul 16 16:44:49 <ogra_> hard to tell, i havent had one that booted this release cycle
Jul 16 16:46:42 <ogra_> janimo, not precise
Jul 16 16:47:30 <ogra_> ogra@anubis:~/Desktop/tegra$ ls lib/modules/3.0.27-1-ac100/kernel/
Jul 16 16:47:30 <ogra_> drivers  fs
Jul 16 16:47:49 <ogra_> no nls ... but fat avd vfat are in the fs subdir
Jul 16 16:47:52 <ogra_> and they worked
Jul 16 16:48:37 <ogra_> probably nls was compiled in and is now modular ?
Jul 16 16:49:16 <janimo> ogra_, you got it, that
Jul 16 16:49:19 <janimo> is the issue
Jul 16 16:49:23 <ogra_> :)
Jul 16 16:49:25 <janimo> I'll revert it
Jul 16 16:49:28 <ogra_> thx
Jul 16 16:49:37 <ogra_> btw, the installer can also use ext2
Jul 16 16:49:58 <janimo> ah, so not showstoper but mportant still
Jul 16 16:50:03 <ogra_> right
Jul 16 16:50:18 <ogra_> annoying if you used vfat and have to re-do your SD though
Jul 16 16:50:59 <marvin24> may I ask if tfx01 suffers from the same console problem?
Jul 16 16:52:05 <ogra_> lilstevie, ^^^
Jul 16 17:01:25 <scientes> IMHO you guys should be using your own 3.2 kernels
Jul 16 17:01:45 <ogra_> ou own ?
Jul 16 17:01:47 <ogra_> *our
Jul 16 17:01:59 <scientes> precise is 3.2
Jul 16 17:02:19 <ogra_> not for ac100
Jul 16 17:03:18 <ogra_> we only had a 3.0 tree for qunatal
Jul 16 17:03:43 <ogra_> err
Jul 16 17:03:48 <ogra_> precise indeed
Jul 16 17:03:59 <scientes> is it tegra 2 or something, and you are held back by old shit?
Jul 16 17:04:14 <scientes> *binary shit
Jul 16 17:04:25 <ogra_> it is tegra2 and we are depending on nvidia and chromeos commits
Jul 16 17:04:37 <gildean> all tegra2 devices are held back afaik, i've not seen a tegra2 device with a modern kernel
Jul 16 17:04:51 <ogra_> yep
Jul 16 17:06:00 <gildean> and i have three different tegra2 devices atm
Jul 16 17:06:31 <gildean> fortunately paid for none
Jul 16 17:06:36 * ogra_ too
Jul 16 17:06:42 <ogra_> but i paid for some :)
Jul 16 17:07:41 <gildean> i could've bought a galaxy tab 8.9 if i didn't get one from work
Jul 16 17:11:25 <scientes> eek, its 3.4 kernel feature
Jul 16 17:11:29 <scientes> guess I can't ask for that
Jul 16 17:11:36 <scientes> even though quantal will have it
Jul 16 19:38:09 <janimo> marvin24, it keeps being unclear to me whether we need CONFIG_PCI in the ac100 kernel
Jul 16 19:38:31 <janimo> I think it used to be both on and off (PCIE too) with no noticable effect as far as I remember
Jul 16 19:39:26 <janimo> I am looking at the config changes introduced with the 3.1 kernel, as one slipped through and lead to unmountable fat partitions
Jul 17 00:35:41 <lilstevie> marvin24, if you mean the blank console issue where you get no kmesg with fbcon enabled, no, it only affected us for 2.6.39, at least on the tf201, there isn't a good solid properly ported tf101 3.1 kernel yet to comment on, so it could possibly be a tegra2 bug
Jul 17 02:20:24 <robclark> btw, anyone tried kde / kwin_gles?  It seems like /usr/lib/kde4/kcm_kwincompositing.so is linked against libGL.so instead of gles (this is w/ kde-window-manager-gles)
**** ENDING LOGGING AT Tue Jul 17 02:59:58 2012