[00:23] cvanvliet_: Using them from where? === unknown|2 is now known as yangster === gildean_ is now known as gildean === rsalveti` is now known as rsalveti === cvanvliet_ is now known as cvanvliet [06:38] infinity, http://elinux.org/BeagleBoardUbuntu#SGX_armel.2Farmhf_v3.4.x.2B [06:39] hm. tried the omap4 netboot installer, but board does not boot afterwards. 12.10's boot.img-serial.gz should be right? [06:40] or rather boot.img-fat-serial? [06:44] LetoThe2nd: boot.img-serial.gz should be fine if you zcat it to a card. If the installer ran all the way through, the image was fine. [06:44] LetoThe2nd: But it's entire possible that it doesn't produce a bootable system in quantal. [06:44] ogra_: Is flash-kernel-installer not doing nice things in quantal? I've heard a few reports of netboot not producing bootable systems. [06:45] infinity: it ran all the way. ah, i see. will give it one more try with 12.04 for now [06:45] LetoThe2nd: 12.04 should be just fine. We use it all the time. [06:45] infinity: yeah, i just hoped i could already give 12.10 some testing [06:47] ah, and one more thing - do the arm port repos also provide rt-enabled kernels like for x86, or is there opportunity for playing? [07:04] infinity, I have asked in #beagle as well, I will let you know if I get any follow up, (afk) [07:55] hm, netinstall with precise also did not result in a bootable sd card. :( [08:59] ok, now i am pretty convinced that there is something fishy with the netboot installer taken from http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/boot.img-serial.gz [09:00] tried now twice with different sd cards, two times system is not booting anymore after successfully completing the installer. [09:00] file a bug, attach as many logs as you cnan find :) [09:00] image was written to block device using zcat image > device... everything correct so farß [09:01] right, but that image is a single partition image, flash-kernel doesnt know how to write to a device instead of to a partition [09:01] ogra_: hence? [09:01] well, at least for omap4 it expects to have mmcblk0p1 [09:02] you could check if it still boots when you partition your SD first and then dd to the first partition [09:02] ogra_: can do that. [09:03] ogra_: something like creating a 60M fat16 partition on the blockdevice and then zcatting to that? [09:03] right [09:04] will do. report back in some minutes [09:04] thx [09:05] using the automagic partitioning afterwards is ok? [09:05] yes [09:06] it shouldnt care about the SD [09:06] only flash-kernel will in the end [09:06] ogra_: does not even boot. [09:07] ah, sad [09:07] indeed. [09:07] i'll look into it [09:07] thx [09:07] thanks for telling me [09:08] np. [09:08] shall i walk though the process once more using the block directly for zcatting, so i can inspect the card afterwards? [09:08] that would be helpful, yes [09:09] np, will be ready after lunch i guess. === zyga is now known as zyga-afk === zyga-afk is now known as zyga [11:05] ogra_: back with the sd card :) [11:05] so what does it show ? [11:06] ogra_: after the finished install process, the favorite symptoms of any pandaboard user: power on -> status led 2 solid on. [11:06] hwo does the SD look like ? [11:06] *how even [11:07] http://paste.ubuntu.com/1098130/ [11:08] besides that, black and on the front side is printed "micro sd card 4gb class 10", on the back side it has some copper coloured contacts. [11:08] *SCNR* [11:09] oh, wait, you installed *to* the SD ? [11:10] janimo, ac100 images work fine now, thanks for all the help (the tegra driver in the archive makes lightdm end up in a restart loop though, i just uploaded the new tegra driver, lets see if that works) [11:10] ogra_: roger that [11:11] hmm [11:11] i assume /dev/sdd1 contains /boot ? [11:12] ogra_: i guess so, its what installer automagic created. [11:12] right [11:13] LetoThe2nd, bug 872525 [11:13] Launchpad bug 872525 in partman-uboot "No option for u-boot partition on armel omap/omap4 platforms" [Medium,Triaged] https://launchpad.net/bugs/872525 [11:14] ogra_: want me to try gruemasters suggestion? [11:14] that would be helpful [11:14] if that works i'll take a look at how we can default to that setting with a default preseed entry [11:15] ogra_: will take some time, probably about an hour. gonna report back then. [11:15] great, thanks [11:15] * ogra_ will meanwhile take a look at the preinstalled server images [11:17] ogra_: What was the reason for changing the panda images from preinstalled to live? [11:18] TheMuso, bad user experience due to bad I/O on SD cards [11:18] TheMuso, and the fact that it takes some effort to maintain the preinstalled stuff separately ... with the switch to live we just use what all other arches use [11:19] * TheMuso nods. [11:19] which reminds me ... [11:20] * ogra_ needs to update the alsa UCM stuff for the pandaboard, seems they renamed the device *AGAIN* ! [11:20] UCM stuff is still very much in development it seems. [11:20] i hope they run out of names at some point [11:21] well, it worked (kind of) in precise and oneiric on the panda and the ac100 [11:21] Well I'll be able to help with testing at least... Jason got panda boards for all desktopt team members, so as soon as I get a USB drive box, my panda will be running quantal. [11:21] yippie ! [11:22] I probably still need to get extra bits, as I'd like to try and test 5.1 HDMI audio if possible. Got a stereo HDMI monitor, but I'd rather make sure everything works. [11:22] ogra_: And are the gstreamer bits for omap4 available in precise? I see there is a driver via jockey, but what about the rest? [11:23] no, TI didnt make them available for the kernel we have in precise [11:23] Shame. [11:23] there is a TI PPA that has them and an unsupported TI kernel package [11:23] Ah ok. [11:34] ogra_, \o/ for the final tegra graphics drivers! [11:34] well, lets see if they work :) [11:35] they already built, waiting for the publisher [11:35] let's see how the new nvidia rebased kernel works, there may be regressions compared to precise [11:35] there surely is an issue with the alsa parts [11:35] i see a lot related messages [11:35] marvin24, I went ahead and rebased our packaging tree (so your patches included in last package) on nvidia's l4t-15 branch [11:36] I'll do a new rebase or cherry-picking for the changes you have added since sometimes soon [11:37] I do not use the ac100 enough to know what kernel things still need fixing, so am a bit surprised to see new commits still being added as if there were actual issues :) [11:37] "tegra-alc5632.0: only stereo is supported in I2S mode" is what i get over and over in dmesg [11:37] (until i run sudo alsa force-unload to quieten it) [12:04] ogra_: nope, does not help [12:04] ok [12:05] probably partman-uboot is completely missing or so [12:05] i'll inspect it, as i said ... [12:05] the choice item was labeled a bit different "use longest contiguous free space" or so, it didn't fix it. [12:05] ogra_: I should have my USB box tomorrow, so plan to do a net install then, if I get the same problem I'll do some digging as well, that is if you don't get to it today. [12:05] janimo, oh, disregard the moaning about alsa, i didnt run the new kernel yet, it was not on todays image [12:06] TheMuso, great, thanks [12:06] oh, so it may actually be much worse :) [12:06] lets see ... rebooting [12:06] I just ran a simple zImage to see it boot till tarbgall installer [12:06] ogra_: TO confirm, in d-i, do I mark the first partition on the SD card as bootable? [12:07] janimo, hmm, looks like it hangs in fsck [12:07] TheMuso, doesnt matter we dont run DOS ;) [12:07] janimo, yeah, definitely [12:07] ogra_: So I just ignore the SD card at partitioning time? [12:08] janimo, now it prints a message: "rcu_sched_state detected stall on CPU 1 (t=6000 jiffies)" [12:10] janimo, hmm second try works (still the same issue with lightdm constantly respawning though) [12:11] ogra_, is this after a successful install with the previous kernel and ext2? [12:11] and the alsa messages are back as well [12:11] janimo, right, todays image [12:11] can lightdm respawning be related to l4t or is this with fbdev? [12:11] then i installed the tegra driver, updated it ... and then pulled linux-ac100 [12:11] well it started with l4t [12:12] (before i upgraded the kernel) [12:12] but it can indeed be a missing bit in our kernels [12:12] which the final driver uses [12:13] hmm, intresting, startx works [12:13] and opening a terminal crashes it ... then it spills about 2000 alsa errors on the consile [12:15] *console [12:16] * ogra_ purges the nvidia driver [12:19] janimo, ok, without the driver i get lightdm to work, but still have the alsa errors (sound works though, its just extremely niosy in dmesg) [12:20] ogra_, so it worked with the newest tegra driver and the previous kernel? [12:20] yes [12:20] err, no [12:20] sorry [12:21] Xorg.0.log only has a segfault, no further errors [12:32] janimo, for whatever reason my syslog is full of "fuse.ko: Invalig Argument" [12:32] *invalid [12:50] oh, i just noticed the new driver ships new udev rules and an upstart init script [12:50] SHRIEK !!!!!!!!!!!!!!!!!!!!!!!1111 [12:51] first command in that initscript is: chmod 0666 /sys/power/state [12:52] oh, intresting ... all hardcoded sysfs paths in there have tegra3 in their pathname [12:54] seems even though it is a ventana package it expects tegra3 devices [13:03] janimo, hmm something is definitely weird with the fuse module [13:04] it complains that fuse is loaded already if gvfs tries to load it on desktop startup ... but lsmod disagrees [13:10] ogra_, I'll do an install myself today or tomorrow and look at the issues that piled up. [13:10] k [13:10] I need to start using the ac100 myself it has been just standing there doing nothing for a good while [13:11] i'll try to find out why the tegra driver fails ... [13:11] yeah, i moved to a shiny new desktop myself [13:11] ogra_, so you're back on x86 again :) [13:12] didnt touch the ac100's for a while, quad core, 16G and a super fast SSD somewhat spoiled me :) [13:12] mumble, mumble, kernel cross-compilation, mumble mumble [13:12] * ogra_ even started plaing games again in the evenings [13:12] ya ya ... i'll set up a cross env some day [13:13] I keep saying that for almost 2 years but I should probably get myself one of those fast systems too. I do too much building and that would help [13:13] atm i try to fiull my 3TB HDD with images and a debmirror ... iÄ'll surely add several kvm's and cross chroots [13:13] ogra_, it is not much of a cross env, no need for qemu and other junk for kernel. Just cross-gcc and you're done, so a single apt-get install :) [13:14] well, i want to keem the host system completely clean and do all work in chroots [13:14] *keep [13:14] for full package builds yes, chroots and whatnot is needed, but kernel builds are really simple [13:14] preferably having them tarred up and unpacking them on the fly to a tmpfs [13:14] having fast ssd and lots of RAM allows such complicated setups I guess [13:14] somehow i cant get the system to use more than 9-10G of the ram ... [13:15] so i can eat the rest with tmpfses [13:15] isn't there something like SETI at home but which eats RAM instead of CPU cycles? You should try that [13:15] "tegra-alc5632.0: only stereo is supported in I2S mode" is what i get over and over in dmesg [13:15] that should allow cross builds in minutes :) [13:15] or pull ;-) [13:16] marvin24, pull ? [13:16] git pull? [13:16] oh, a fix ! [13:16] great [13:16] i just blacklises all sound stuff for now ... [13:16] *blacklisted [13:17] concentrating on the xorg issue [13:17] i wonder if that driver is supposed to work with this kernel at all [13:17] startx actually gets me a full desktop but X crashes as soon as i click something [13:18] marvin24, I tried cloning your tree again yesterday but gitorious would not let me. I'll try again these days [13:18] and all info i can get is "Segfault at 0x86" [13:18] in Xorg.0.log [13:20] * marvin24 didn't tried the new driver yet [13:20] I only heard of troubles so far ... [13:23] so lets see how well hrw did his job ... [13:23] * ogra_ installs gcc-arm-linux-gnueabihf for the first time evar [13:25] ;) [13:25] ogra_: if you want to build !kernel then also 'apt-get install libc6-dev-armhf-cross' [13:25] will do [13:29] ogra_, hmm I may have lied when telling you there's a single package needed. I remember hrw telling me I need that too but now I do not recall why it was needed for exactly [13:29] http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/ [13:30] thats enough for me :) [13:30] ogra_, you mean to build full debs not just zImages? [13:31] ogra_, this is what I usually use debuild -eDEB_BUILD_OPTIONS="parallel=3" -eskipabi=true -eskipmodule=true -eCROSS_COMPILE=arm-linux-gnueabihf- -b -aarmhf -us -uc -nc [13:32] you can make the parallel much more I guess [13:33] I also usually set tools=false in debian.*/rules.d/armhf so I don't have to cross install other deps for linux-tools [13:33] but for quick testing I just build zImage [13:37] yeah [13:48] hmm, so our kernel doesnt have NVHDCP enabled [13:49] and there seem to be a few new NVMAP options to play with [13:49] oh, and we dont have /dev/nvram enabled at all [13:56] hmm, building definitely doesnt work as advertised [13:56] (cross building that is) [13:57] nope, cant make it build [13:58] aha, only works if CROSS_COMPILE is set [13:58] janimo, i think there was something added to the linux package scripts to automatically set that in ubuntu kernels when cross building a package ... are we missing a merge ? [13:59] ogra_, CROSS_COMPILE needs setting in env when doing simple make zImage [14:00] janimo, it shouldnt for the package [14:00] also in the debuild line I pasted above [14:00] yes, but not in hrw's howto [14:00] not sure if we are missing something, I did not work on other arm kernel packages [14:00] and i think the kernel team enhanced the scripts to auto xport that var during package builds [14:00] I know, no idea really I just stuck to what works and what I learned last year here: https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel [14:01] ogra_, they may have done that, in which case I did not know about it to incorporate in our scripts [14:01] I will if I find out :) [14:01] there was a ML discussion a while ago during precise [14:01] I pasted that line to show what I used all the time and what worked for me for ac100 and armadaxp kernels too [14:02] right, that works here too (despite the fact that i dont like debuild and use dpkg-buildackage) [14:04] wow, that was fast (failed in tools since i didnt suppress them) [14:09] wow, i actually got all four cpu cores at 50°C ... havent seen them above 30 since i built that thing [14:10] ;) [14:12] curse m4 for lack of ifndef [14:27] grrr [14:27] i cant get past the failing tools [14:27] do_tools=false as documented everywhere doesnt seem to have any effect [14:40] oh CRAP ! [14:40] so debian.linaro overrides all defaults ? [14:40] *SIGH* [14:48] real 5m49.016s [14:48] user 13m47.740s [14:48] sys 1m23.897s [14:48] nice ! [15:26] ogra_, did you only use parallel=3? user/real suggests something like that [15:26] =8 [15:27] or maybe kernel builds is more deb packaging and linking that parallelizable compilation [15:27] i thought 4 cores should be able to handle 8 threads :) [15:27] ogra_, they do, but the last bits - the packaging ones - are likely only using 1 thread [15:27] indeed [15:27] probalby with plain make zImage you'd get a much better ratio :) [15:28] but anyway, nice to have such fast turnaround now [15:28] oh, definitely, but with 13min for a package build i wont complain :) [15:28] 13 user, real was 5 no? [15:29] yep === Ursinha` is now known as Ursinha === npitre_ is now known as npitre === gildean_ is now known as gildean [21:18] ahs3`: *poke* [21:19] ahs3`: That python-greenlet patch probably shouldn't be using uname to set CFLAGS in setup.py, since that's depending on the buildd environment, rather than the target. [21:20] ahs3`: (In our case, it'll just get set universally for armel/armhf, since all our machines have that uname, but it still seems sketchy in the case where that's not true) [21:20] infinity: hrm. is that the part that adds -fomit-frame-pointer? [21:20] ahs3`: Yeah. [21:21] ahs3`: I could just as easily be building on an armv5 machine with -mcpu=armv7-a, and that flag then wouldn't get set, though it should be. [21:22] ahs3`: Seems harmless for the SRU and for our current buildds, but still inappropriate (IMO) for upstreaming. [21:22] ahs3`: Then again, upstream seems to suffer that issue elsewhere too, so.. [21:23] infinity: right. latest upstream has already moved well past this version and it's not needed there. but, there are several other ARM patches in 0.3.4 [21:23] ahs3`: Mmkay. Then it doesn't bug me *as* much. [21:23] ahs3`: (I note that upstream makes the same mistake with a uname=i386 check, so at least it's consistently broken) [21:23] infinity: well, and bumping versions for SRU is a no-no, yeah? [21:24] ahs3`: I assume this omitting of frame pointeryness won't break armel while fixing armhf? [21:24] infinity: lol. oh, goody, we're consistently broken :) [21:24] ahs3`: Yeah, bumping upstream versions is a no-no unless absolutely needed. I'm much happier with the backported patch option, as long as it works. [21:25] infinity: i don't believe this will hurt armel; this only shows up in armhf [21:25] (the bug, that is) [21:26] Except, wait... [21:26] -fomit-frame-pointer is included by default in -O2 anyway. [21:26] Is there somewhere else where this is being forced to -O0 or something? [21:27] not that i ever found :(. the only reason that's there is that it was not showing up on the gcc line when building [21:27] i presumed that was being echoed correctly [21:28] Right, it's in the default set. [21:28] You'd need to use -fno-omit-frame-pointer to explicitly ask for the inverse. [21:28] So, that part of the patch is probably a no-op. [21:29] probably so; re-running the tests would confirm [21:29] Anyhow, it's harmless either way, I'm not going to make anyone retest and reupload, if you know this version works. [21:29] And if upstream no longer has that bit of code, all the better. [21:29] it does. tested on armadaxp, on precise [21:30] yup, plus other ARM fixes that would be nice to have, but oh well [21:30] Well, feel free to backport more fixes. :P [21:31] Unless the new upstream is really just "nothing but more ARM fixes", then we can talk version bumps. [21:31] ahs3`: For now, accepting this into proposed. [21:31] infinity: thx. unfortunately, it's a bunch more than just ARM stuff [21:32] Well, even if the new upstream is "nothing but bugfixes with no new features", we could perhaps talk about that. [21:32] But it's not even in quantal yet, so... [21:32] We'll cross that bridge if anyone feels the urge to later. [21:32] actually, it's already in quantal [21:33] Is it? I thought Q was 0.3.3... You were talking 0.3.4 [21:33] hrm. lemme look. i thought zul had gone to 0.3.4... [21:34] Nope, and Debian's still at 0.3.3 as well. [21:35] Bah, and the mips ASM is broken too. Is that fixed in 0.3.4 as well? [21:35] If so, I might just NMU the new upstream. :P [21:35] d'oh. yup. 0.3.3. [21:35] lemme check the changelog. i don't recall seeing mips fixes, but i wasn't looking for them [21:37] platform/switch_mips_unix.h: In function 'slp_switch': [21:37] platform/switch_mips_unix.h:43:1: error: $fp cannot be used in asm here [21:37] error: command 'gcc' failed with exit status 1 [21:37] It's so lovely when people write assembly blind. [21:37] (I can only assume it was blind, since it's pretty obviously broken) [21:38] looks like the last mips change (at least in the switcher code) was in 2010 :( [21:38] Yeah, I'm seeing that. [21:38] So, something externally broke it. [21:38] Oh well. [21:39] I don't have any mips machines to test on, and I can't see obvious breakage at a glance. [21:40] Can I just go on the record as saying that python modules with hand-tuned assembly are a bit of a giggle? [21:41] ahs3`: 3.3 [21:41] lol. absolutely. it is one of the more amusing bits of code i've seen [21:42] zul: nod. i got 0.3.4 stuck in my head for some reason [21:42] Anyhow. I might NMU ARM fixes into Debian, which would bring us in line (except for the dh_python2 switch), but that won't actually help the RCness in Debian, due to the mips breakage. :/ [21:43] And if ARM is fixed upstream in 0.3.4 anyway, that seems like it might be wasted effort on my part. [21:43] Erk. [21:44] ahs3`: Is the testsuite still disabled in precise due to this breakage? [21:44] ahs3` / zul: I may prefer to see "turning the testsuite back on" as part of the SRU, to prove it's all better. [21:44] infinity: dunno. i don't think it was ever ENabled [21:44] ahs3`: It's enabled in Debian, it's disabled in our packages because it was segfaulting on ARM. [21:45] infinity: ah. then you should be able to enable it again; that's what was used to test the patch [22:04] ahs3`: Alternately, this package is too much of a mess for me to try to make sense of. :P [22:04] ahs3`: If someone tests the output of the buildds, I'll just scream LA LA LA and ignore the testsuite still being off. [22:05] infinity: fair enough. testing we can do. === TheMuso` is now known as TheMuso === wgrant_ is now known as wgrant