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 | 13:08 |
=== zyga is now known as zyga-food | ||
=== zyga-food is now known as zyga-food] | ||
=== zyga-food] is now known as zyga-food | ||
=== zyga-food is now known as zyga | ||
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:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:39 |
lilstevie | need to sync to that tag myself | 14:40 |
* ogra_ didnt have any issues with our kernel and the v15beta | 14:40 | |
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:41 |
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:42 |
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:43 |
ogra_ | pfft ... it trains your fantasy | 14:44 |
lilstevie | lol | 14:44 |
lilstevie | in any case, makes accelerated unity unusable | 14:45 |
ogra_ | right, currently: use a panda for that :) | 14:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
ogra_ | but we use that kernel :) | 14:55 |
janimo | lilstevie, we use his kernel for ac100 in ubuntu | 14:55 |
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:56 |
lilstevie | it is a nightmare due to a bunch of OEMs using the same mtype | 14:57 |
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:58 |
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 | 14:59 |
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:00 |
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:01 |
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:02 |
marvin24 | maybe I should also start to tag ... | 15:03 |
lilstevie | I haven't seen the r15 hdmi code in 15r7 | 15:04 |
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:06 | |
janimo | lilstevie, you're on transformer prime? | 15:07 |
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:09 |
ogra_ | janimo, http://cdimage.ubuntu.com/daily-preinstalled/20120716/quantal-preinstalled-desktop-armhf+ac100.bootimg | 15:11 |
ogra_ | abootimg -x gets you the initrd from it | 15:12 |
ogra_ | btw, is there any reason why we use tty1 not tty0 ? | 15:12 |
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:15 |
ogra_ | janimo, cool, thanks, i will aslo try to experiment with different and smaller initrds | 15:16 |
* ogra_ switches the default to tty0 | 15:17 | |
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:18 |
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:19 |
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:20 |
lilstevie | hm | 15:21 |
lilstevie | volume is killing me :/ | 15:24 |
lilstevie | I have no volume control on the prime | 15:25 |
lilstevie | either sound is on, or muted | 15:25 |
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:27 |
lilstevie | people use armel builds? | 15:28 |
scientes | doesn't infinity run those? | 15:28 |
ogra_ | the canonical IS team runs all buildds | 15:29 |
ogra_ | (no matter what arch) | 15:29 |
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:30 |
janimo | lz packed size is : 2049358 | 15:31 |
janimo | quite under the 2M limit | 15:31 |
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:32 |
ogra_ | will check how hard it is to switch it (iirc i already ship a specific initramfs-tools.conf) | 15:34 |
ogra_ | ah, sad, thats only the in-initrd config | 15:35 |
ogra_ | fix uploaded :) | 15:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
scientes | thats ok for me, debian works fine | 15:54 |
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:57 |
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:58 |
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 | 15:59 |
ogra_ | janimo, i still get stack-protector kernel errors here :( | 16:06 |
ogra_ | no matter if i use xz or lzma | 16:06 |
ogra_ | grmbl | 16:16 |
ogra_ | still corrupted kernel stak :( | 16:16 |
ogra_ | *stack | 16:16 |
* ogra_ hates kernels | 16:17 | |
ogra_ | why cant we live without them ! | 16:17 |
cooloney | ogra_: oh, come on | 16:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
* ogra_ pulls and tests | 16:27 | |
janimo | but it cannot find the tarball on the usb stick | 16:29 |
ogra_ | bah ! why does that boot | 16:29 |
ogra_ | janimo, yeah. looks like a live-build issue, the installer.md5 file has a wrong name | 16:30 |
ogra_ | janimo, oh ! | 16:31 |
ogra_ | the kernel misses cp437, it cant mount | 16:31 |
ogra_ | (needed for vfat) | 16:31 |
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:32 |
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:33 |
janimo | ogra_, lz for initrd or the whole squashfs? | 16:34 |
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:35 |
ogra_ | janimo, http://people.canonical.com/~ogra/tegra/quantal-preinstalled-desktop-armhf+ac100.bootimg | 16:36 |
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:37 |
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:38 |
scientes | i have no idea how it manages to fail on your modern hardware... | 16:39 |
janimo | ogra_, nothing changed in the configs AFAICT 437 is there in the configs | 16:42 |
* ogra_ scratches head | 16:42 | |
janimo | ogra_, although there's no nls/*ko in lib/modules in the initramfs | 16:43 |
janimo | kernel/fs/nls is nonexistent | 16:43 |
janimo | I wonder if earlier initrds had that | 16:44 |
ogra_ | hard to tell, i havent had one that booted this release cycle | 16:44 |
ogra_ | janimo, not precise | 16:46 |
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:47 |
ogra_ | probably nls was compiled in and is now modular ? | 16:48 |
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:49 |
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:50 |
ogra_ | lilstevie, ^^^ | 16:52 |
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:01 |
ogra_ | not for ac100 | 17:02 |
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:03 |
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:04 |
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:06 |
gildean | i could've bought a galaxy tab 8.9 if i didn't get one from work | 17:07 |
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 | 17:11 |
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:38 |
janimo | I am looking at the config changes introduced with the 3.1 kernel, as one slipped through and lead to unmountable fat partitions | 19:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!