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