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