[07:08] I have a question about programs [07:08] If I download the source to pd extended will it build on u-arm? [07:09] * persia checks [07:09] Sorry I'm seriously daft [07:10] I just hear all this jazz about stuff not porting well to arm and I was wondering if I was missing something, the program in question only uses c, c++ and tcl supposedly [07:10] Well, puredata seems to be built. I'm not sure why pd-extended wouldn't. [07:10] But since I'm not finding pd-extended available, I'm guessing it's not already done. [07:10] So no issues on arm arch [07:10] (but I also don't see it in the build failure report, so I presume it's out-of-archive) [07:11] There's source and it builds on ubuntu on my desktop [07:11] Which Ubuntu source package? [07:11] But I'm wondering if it'll build on an sbc Im getting [07:11] 9.10 I think [07:12] Oh the package sorry I'm real slow tonite [07:13] Well, http://qa.ubuntuwire.com/ftbfs/karmic.html is the fail-to-build-from-source report for 9.10 [07:13] So, if puredata needs a package there, it ought fail, but it appears puredata succeeded, so I suspect it would work. [07:14] http://puredata.info/downloads [07:14] Ok cool [07:14] So the whole portability q I keep seein on this hardware forum is about other stuff [07:15] I guess I was wondering what issues I might run into just using make etc on the source on an arm setup [07:15] I thought I remembered a pd-extended source package, but I'm not finding it now. [07:16] Most of the issues seem to either be related to upstream being insufficiently portable (for instance, wine doesn't compile), issues with ARM vs. Thumb2, or issues with the toolchain. [07:16] I believe the karmic toolchain to be mostly clean. [07:16] Groovy [07:17] Really I just need pd and the gem library [07:17] Sounds solid now [07:17] pd and gem should be available with apt-get [07:18] Nice [07:18] Depending on your kernel, you may end up with issues at lower levels, but at the high levels, all is good. [07:18] Making an effects box? [07:18] Actually just trying to get a smaller computer for generative music and video stuff [07:19] Also I preordered a pandora [07:19] I figure in the end I'll rock pandora but maybe angstrom if it wows me [07:21] Well, best of luck with that. I think you may want a USB audio interface though, if you're looking at input/output. I don't know of many SBCs that have high-def audio systems. [07:21] Pandora has enough for what I'm gunna rock [07:21] Cool! [07:22] Usually our sound guys push the faders up too much anyway [07:22] Hehe [07:22] heh. Then it doesn't matter if you have perfect DA converters :) [07:22] Yeah... This has only made me more excited for my open pandora [07:26] Thanks a bunch for helping [07:26] I was pretty sure it would just build but I won't be certain till my hardware is here [11:07] hmm, so all plymouth error messages are gone with my new babbage install [11:07] \m/ [11:07] reinstall from A2 and dist-upgrade seems to have worked fine [11:07] i even have suspend/resume working properly [11:08] And is plymouth actually running? [11:08] i dont think so, let me check [11:08] the console fonts change during boot so it might be [11:08] i.e. i see some bold parts in the fsck output [11:09] Could be something else, depending. I don't know how karmic works, but I do know it's fancy (and different to both jaunty and lucid) [11:09] hmm, should i see a logfile or something ? [11:10] i know there is a plymouth-log process usually [11:10] No idea, sorry. [11:10] well, i'll reboot [11:19] i dont see any splash ... but [11:19] i can run plymouthd manually and run plymouth --show-splash and see a moving bar at the bottom of the screen on tty8 [11:19] its odd that X is on tty1 now :( [11:20] makes my finger memory unhappy :) [11:22] It makes for no VT switch, which is apparently both faster and more appealing. [11:22] But I'm glad to hear it works. [11:23] well, seems plymouthd defaults to tty8 [11:23] so if it doesnt do a vt switch and stays on vt1 there is indeed no way for me to see it [11:25] hrm. [12:07] * ogra wonders why motd tells him he can update 285 packages [12:07] i just did a dist-upgrade [12:08] asac, so plymouth dies because of the console comdline option we use [12:09] The console command line? The kernel command line? [12:10] yes [12:10] And if we use a different one, it works? [12:10] the "moutall: could not connect to plymouth" goes away if i remove "console=ttymcx0,115200 console=tty0" from the cmdline [12:11] And where does console end up? [12:11] also the plymouth-log error [12:11] tty0 [12:11] as its supposed to [12:11] the A2 install i had didnt set console, now that i switched to uboot i have a console entry [12:11] Well then, that sounds like a reasonable thing to fix. [12:12] if i remove it and make it look like the redboot line we install it works [12:12] Cool! [12:12] That's fancy demo stuff, there. [12:12] as soon as i enforce a tty by using console= it breaks [12:15] hmm, let me try tty8 ... probably plmouth runs already but i dont see it [12:15] 285 packages can be updated. [12:15] 0 updates are security updates. [12:15] GRRR [12:15] liar !!! [12:16] Run update-motd to make it go away. [12:16] ogra@babbage2:~$ sudo update-motd [12:16] sudo: update-motd: command not found [12:18] Hrm. Dunno. Worked in jaunty. I haven't played with update-motd in karmic, but I don't see a binary. Ask mvo or kirkland. [12:19] Last time I found a bug it got fixed within two days. [12:20] not so pressing now [12:20] * ogra is more intrested in seeing plymoutho [12:20] -o [12:20] heh [12:21] so tt8 quitens down even more but doesnt make plymouth work [12:22] * ogra looks at /usr/share/initramfs-tools/scripts/init-top/plymouth [12:22] printf '\033[?25l' > /dev/tty7 [12:22] /sbin/plymouthd --mode=boot --pid-file=/dev/.initramfs/plymouth.pid [12:22] /bin/plymouth --show-splash [12:22] hmm [12:23] whats that printf ? a clear command ? [12:23] show (or hide) cursor [12:23] * ogra tries console=tty7 [12:25] nope [12:25] doesnt work either [12:25] and i see a cursor :) [12:29] GAH ! [12:29] my X crashed [12:31] You didn't really need that, did you? [12:32] printf '\033[?25l' > /dev/tty works in a xterm here :-) [12:32] * ogra slaps persia with a wet towel [12:33] lool, well, i guess it works on my tty7 too during boot, prob is that i'm on tty0 by default (so i cant see it) and that plymouth doesnt seem to like if i set console= [12:34] Does Alt+Fn7 not switch for you? [12:34] Or can you change the config? [12:34] sure it does, but way to late :) [12:35] You clearly need to find some way to slow down the boot :) [12:35] ogra@babbage2:~$ man plymouthd [12:35] No manual entry for plymouthd [12:35] BOOO ! [12:35] ogra@babbage2:~$ man plymouth [12:35] No manual entry for plymouth [12:35] BOO++ [12:36] See, this is why I think we ought to insist on agressive peer review for all new packages. Even the best of us skip stuff. [12:36] (and this annoys users, like you) [12:44] dmart, you around? [12:45] had to join first ;) [12:45] NCommander, hi [12:45] dmart, I need to poke your brain, I've had some thoughts on the vldr issue we have on ARM, and I was wondering if you can give your input on this [12:45] s/ARM/Dove/g [12:45] sure [12:46] dmart, I've been looking at the Marvell kernel fixup for vldr, and I think the issue with it is that the vldr fixup doesn't fire until after the processor sends an alignment fault to the kernle [12:48] dmart, (I might be mistaken on this part, I'm not very familiar with kernel code handling alignment) [12:50] I think that's normal? User: vldr *boom* -> kernel: fault kandler -> emulate unaligned vldr -> return to userspace following the faulted instruction [12:50] s/kandler/handler [12:50] dmart, right, based on how the kernel handles alignment faults, that was my understanding as well [12:51] dmart, the problem then is impossible to fix in kernelspace because the kernel doesn't vet each individual instruction [12:51] (or at leas tin this portion of kernel space) [12:52] dmart, there are two ways we can work around the faulty vldr instruction, 32 vmov's, or force the processor into ARM mode for the execution, then return to Thumb2 (if the context is appropriate for the switch) [12:52] not sure which one is faster [12:52] (I'm guessing returning to ARM mode is going to be faster, but I wanted to run that by you) [12:57] dmart: you can also reply to me ;) [12:57] ah there he is again [12:57] nm [12:58] ugh, sorry [12:58] router decided a lovely time to HCF [12:58] What was the last thing that you saw from me? [12:58] Time can7t reach him, but timeouts can :) [12:58] [21:53] (I'm guessing returning to ARM mode is going to be faster, but I wanted to run that by you) [12:59] persia, that sounds like it was from a song. [12:59] was there a response :-) [12:59] No. [12:59] ok, the mount error on imx51 boot seems to definately be bootchart [13:00] * ogra removes it [13:00] * NCommander is looking at his GCC theory [13:00] mount -t proc none $JAIL/proc [13:00] hmm, can that be none ? [13:00] ogra, yes [13:01] * NCommander uses that all the time [13:01] * ogra always thought it *has* to be proc [13:01] Can be any string. It's not read. [13:01] * persia usually uses "proc" [13:01] ok [13:01] me too [13:01] * NCommander usually uses none or its purpose [13:01] proc-hardy on /home/chroots/hardy-i386-android/proc type proc (rw) [13:02] That's why I use "proc", as the context is obvious by $PS1 [13:02] hrm, and it wasnt the error anyway [13:03] ogra@babbage2:~$ grep mount /usr/share/initramfs-tools/scripts/init-top/* [13:03] /usr/share/initramfs-tools/scripts/init-top/bootchart:mount -t proc none $JAIL/proc [13:03] ogra@babbage2:~$ [13:03] but thats the only mount call in init-top [13:03] weird [13:03] * ogra checks the init script itself [13:04] hrm [13:04] ok [13:05] aha [13:05] mount -t tmpfs -o mode=0755 none /dev [13:05] hmm [13:07] Did you want $JAIL/dev ? [13:07] no [13:07] thats what bootchart wanted [13:08] which i removed already [13:08] that line is from init [13:08] Ugh. [13:08] if ! mount -t devtmpfs -o mode=0755 none /dev; then [13:08] mount -t tmpfs -o mode=0755 none /dev [13:08] mknod -m 0600 /dev/console c 5 1 [13:08] mknod /dev/null c 1 3 [13:08] fi [13:08] to be precise [13:11] hmm, is devtmpfs a .32 feature we miss in .31 ? [13:13] I thought it was very new: http://blog.steve.org.uk/we_have_to_be_ready_to_do_anything__do_you_hear_me_.html [13:14] yeah [13:14] well, it was there for a while afaik but experimental [13:14] Seems first introduced April 2009. [13:14] right [13:15] So how isn't this devfs, which everyone decided was bad? [13:15] * persia is confused [13:15] no idea [13:15] i just want the error to go away :P [13:15] Well, get the kernel built with devtmpfs then. [13:16] ogra@babbage2:~$ grep DEVTMPFS /boot/config-2.6.31-602-imx51 [13:16] ogra@babbage2:~$ [13:16] seems we dont even have the option [13:16] Does N appear with that? [13:16] N ? [13:16] Hrm. Then let's drop it from userspace. [13:16] its in init [13:16] Stuff neither selected nor modules, especially stuff that only shows up in submenus. [13:16] and udev uses it massively [13:17] and beyond that it slows down booting to not have it with new udev [13:17] Then lets add it to the backport list :) [13:17] right [13:17] very high up [13:17] where is cooloney when one needs him :P [13:18] slows down booting? So putting initial device management in userspace does slow down boot? Makes me laugh at very old kernel mail threads (back when I actually tried to follow that ML) [13:19] if you use devtmpfs the initial device tree gets directly populated by the kernel [13:19] Right. [13:19] else it will be done by udev scripts [13:19] Right. [13:19] which are slower indeed [13:19] * persia used to use devfs extensively [13:20] looking at some benchmarks google finds for me it seems it removes about 2sec [13:20] I was convinced that the entire approach didn't scale and was ultimately slower, but at that point I was mostly messing with ACPI anyway, and didn't care that much. [13:21] NCommander, sorry, I was away for a bit. What exactly do you mean by "32 vmovs"? [13:22] dmart, 32 vmov instructions to emulate vldr [13:22] yes, but why 32? (I may just be missing the point) [13:22] NCommander, not 32, it could be 2 vmov for vldr or 1 [13:23] 2 vmov for vldr of double word, 1 vmov for vldr of single word [13:23] 32 vmov listed there are for quick expansion [13:24] Yes, I'd expect ldr+ldr+vmov (double) or ldr+vmov (single) [13:25] dmart, you aware of the dove issue right? [13:25] What is the actual problem on Dove? Is it that the alignment fault on a vldr in Thumb-2 can't be handled properly at all for some reason? [13:25] ericm_, oops, misread the code :-) [13:26] * NCommander has not played much with handwritten VFP ASM [13:26] NCommander, I was upset the first time as well [13:26] dmart, the fault never comes, and the board hangs. [13:26] Ah... I see. So we need the userspace code not to do that? [13:26] NCommander, with a latest apt-get upgrade, it looks the system freeze issue has gone, so far no freeze [13:27] dmart, the issue happens only when VLDR is executed in Thumb2 mode, an incorrect alignment fault is generated [13:27] dmart, pretty much, but we have vldr's all over the place, my first theory just crashed and burned [13:28] NCommander, that's what I want to say [13:28] ericm_, I'm going to also see if I can isolate what's causing our counters to run backwards on Dove [13:28] since it still happens with X0. [13:29] That would be very useful to find out. [13:29] NCommander, and asac told me the python bug invokes the system freeze so not clear if it's caused by this VLDR bug though [13:29] Do you know where the problem vldrs are coming from in userspace, or are they just everywhere? [13:29] but yes, the apt-get showing negative could be related to this [13:30] atm our dove images work [13:30] so its not really everywhere [13:30] for me (without knowning) it just feels like dove doesnt like if something "irregular" happens [13:30] like a crash etc. [13:30] dmart, Marvell has a patch to workaround that bug [13:30] if all is fine things seem to work [13:30] dmart, but we are doubting that fixes all the odds [13:31] ericm_: where is that patch? [13:31] already in our kernel? [13:31] asac_, yes [13:31] asac_, wait [13:31] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=1ccfc4f93a746849521afba13ea62aac119c43bd [13:31] To me, the apt-get counter weirdness doesn't sound like it would be caused directly by the vldr issue... unless the fault handling in the patch actually does something wrong and mis-emulates the vldr [13:31] ericm_: is that in the archive yet? [13:32] asac_, already since several weeks ago [13:32] dmart, we've had the issue since before the vldr patch went in :-/ [13:32] right. so we dont doubut ... we _know_ that there are still issues left [13:32] dmart, I agree [13:33] OK, sounds like it's worth digging into the apt-get issue, since something's definitely going wrong reliably in there [13:33] NCommander, but those are different issues - without vldr patch - we know those unalignment faults won't be handled [13:33] not sure though if this ever happens on imx51 [13:33] the negative counter issue [13:34] ericm_, doesn't happen on imx51 [13:34] Has anyone looked at the compiler output for the dove alignment.c patch? There are no output constraints on the vmov_single asm (and it's not volatile) so the compiler might no-op it. [13:35] * ogra files bug 512321 [13:35] Launchpad bug 512321 in linux-fsl-imx51 "please backport devtmpfs to the lucid linux-imx51 kernel tree" [High,New] https://launchpad.net/bugs/512321 [13:35] dmart, let me check [13:35] If you have a .o file handy, it'd be interesting to see it. [13:36] dmart, I'm fairly sure its not no-op'ed since the vldr patch fixed Xorg [13:37] Agreed; it's probably working, though it depends on the compiler behaviour. [13:37] dmart, they are indeed expanded [13:37] a long list of vmov + b, ugly but should work [13:39] Do we have a known, small, sequence of assembly that generates the fault? [13:40] persia, just write a simple test.c with double - I'm pretty sure a VLDR instruction will be generated [13:40] * persia doesn't have HW, so wouldn't know if it caused the issue [13:40] printf("%d", (int)((double)a / (double)b)) [13:40] ericm_ does vldr _always_ fault in Thumb-2? Or is it on occasional anomaly? [13:40] dmart, always [13:41] But I'd think working from a known, small, test case would be easier than working from the entirety of userspace. [13:41] dmart, and Dove X0 fixes this issue [13:41] ericm_, it does? [13:41] NCommander, no alignment fault ever been seen [13:41] NCommander, actually "echo 3 > /proc/cpu/alignment" can reveal all alignment faults on your console [13:42] NCommander, never seen a single on X0 [13:42] ericm_: does import uno hang on X0 ? [13:42] * persia wonders more if it's worth fixing in SW if it only appears for some prerelease dev boards [13:42] asac_, no X0 at hands [13:42] ^- persia [13:42] asac_, will have to come to Marvell office for that [13:43] ericm_: weren't there marvell folks in this channel at some point ;)? [13:43] can we get them back? [13:43] asac_, I think so - but probably not this time :) [13:44] NCommander, did you ever finish your fix for likewise-open ? [13:45] ogra, its unfortunately non-trivial. It gets through 95% of the modules before it blows its brains on the last one [13:45] persia: its definitly worth fixing in SW imo ... what i see is that this bug consumes huge amount of resources. so if we dont fix it, this will probably happen again and again [13:45] or we get all new hardware [13:45] ogra, I know how to fix the last one, but the proper technique is alluding me [13:45] thats ok too i guess [13:45] asac_: Consider my statement a suggestion for option (b) :) [13:46] yeah [13:46] i will discuss this with david today for sure [13:46] NCommander, well, you should probably open a bug with your fixes so far and a description of the ramining issue and your idea for a fix so the server team can do the rest [13:46] ack++ [13:46] *remaining [13:46] please do [13:47] ogra, I take it we got a ping from the server team to look at this? [13:47] NCommander, nope [13:47] oh [13:47] NCommander, it shows up on the FTBFS list [13:47] asac_, NCommander, are we still going to support Z0 BTW? [13:47] i doubt it [13:47] ericm_, we made the call in lucid to drop it [13:47] for now i want Y1 to work [13:47] NCommander, ok [13:47] ericm_, the kernel and the bootloader are fubar'ed for it [13:48] NCommander, its their package, so its fine if they do the rest, but you put work into they should know about [13:53] ericm_, the dove patch does this: addr &= ~3; __get_user(val, (u32 *)addr); [13:54] This won't correctly emulate a misaligned load? [13:54] Or is the problem that we fault on an aligned vldr? [13:54] dmart, the issue they mentioned is only about VLDR in Thumb2 mode [13:55] dmart, I guess the problem is even if it's aligned VLDR, the fault happens anyway [13:55] for an unaligned VLDR, the fault is expected to happen right? [13:56] Yes [13:56] OK. It looks like if userspace really does a misaligned vldr, it will silently load the wrong value instead of getting a SIGILL as it should. [13:56] Mmm.... actually doubt this can correctly handle those unaligned VLDR [13:57] That's what I meant. But there is no handling of unaligned vldr for imx51, and we get no problem there; so I'm not sure whether that situation is happening. [13:57] dmart, indeed - esp. since the compiler is smart enough to get rid of this [13:59] Not necessarily... the common problem is that a library contains a function f(double *a) { do something with a }. a is aligned, right? The ABI says it is. But some caller code built later is munging some freeform data structture: char *p = ; f((double *)p). Strictly speaking that's wrong, but some bits of code may do it. I'd still expect also to see... [14:00] ...problems on imx51 if we hit that case though. [14:00] dmart, yet I expect the support for such faults should be there in the kernel, lemme check [14:01] I think the correct think in the patch would if if(addr & 3) goto fault; [14:01] * NCommander hrms [14:02] I just copied in an apt-get from karmic into a lucid chroot, and I still get backwards running counters :-/ [14:02] dmart, I agree - currently the vldr workaround is placed before other unalignment fault handling code [14:03] dmart, so your proposal will lead to the VLDR workaround to fix only those aligned faults [14:04] ...which I think matches the imx51 behaviour [14:04] dmart, a good catch - will let Marvell guys know this [14:04] It's only a problem for wrong userspace code, so it's more an anomaly than a full on bug [14:04] NCommander, so that doesn't seems to be related to the VLDR issue [14:05] NCommander, maybe it's in libc or somewhere? [14:05] dmart, or one of APT's support libraries [14:06] Hmmm, libutil1, libstdc++6, eglibc (libc6, libm6, libdl2) [14:06] dmart, theres a libapt-pkg* I didn't replace [14:06] let me just fully install the karmic version [14:06] * ericm_ needs some sleep [14:07] 'night ericm_ ... thx [14:07] Oops, yes, libapt-pkg-libc6 [14:08] Thanks. I think the fixup in do_alignment_thumb_vldr is otherwise correct. [14:08] dmart, yeah, that fixed it [14:08] hrm [14:08] Hmmm, so we know which lib it's in [14:09] Cool [14:09] -er- well, it's the same set (deps of libapt-pkg-libc6) [14:09] dmart, actually, its the HTTP handler of APT [14:09] dmart, if I use FTP, the problem goes poof [14:10] Oh right. Is that dlopen'd ? I noticed libdl is linked in there. [14:10] -rwxr-xr-x 1 root root 43K Dec 23 16:28 /usr/lib/apt/methods/http [14:10] Right [14:11] Fetched -656298B in 3s (-191066B/s) - this is just getting annoying :-/ [14:11] unless you can make the clock go backwards too :P [14:12] It is possible to backtract from those printfs and see where the negative answers start to appear...? [14:13] dmart, looking [14:21] dmart, ugh, its a twisty set of includes, and I'm not sure specifically where's going bust [14:23] HMM [14:23] s/HMM/hmm/ [14:26] Z BG [14:26] argh, wrong window again [14:28] Are there any other methods that we could try easily? [14:29] dmart, well, I found the code formatter [14:29] dmart, and I'm testing to see if the number going into that is value or not [14:29] at least gives me an idea of where to look [14:30] Yeah, I guess that's the best thing to do... it it's correct, then we'll need to walk back and see where the number comes from... [14:53] contrib/mmap.cc:246: internal compiler error: Illegal instruction [14:53] * NCommander thunks his head on the desk [14:53] ARGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH [15:02] nice, as suspected dove live image now boots up fine :) [15:02] and plymouth appears to be working nicely as well [15:02] doh, gnome-panel just died though [15:17] plars, "as suspected": what was the fix? [15:18] NCommander, were you building on Dove there? [15:19] dmart: there was a new build of python on Friday, I'm not sure what all is different off the top of my head [15:19] ok, thanks [15:19] dmart: but asac suspected it would help, so I tried with it on Friday and could no longer get pybootchartgui to crash [15:19] dmart: importing uno.py still hangs though [15:20] dmart: but that's just some random thing I discovered while trying to find a simpler testcase... not something that is going to typically be seen during average use [15:20] Is there any relationship to the OOo bug there? I remember uno and exceptions being involved, but can't remember all the background now. [15:24] dmart: asac seemed to be indicating he thought there was some connection [15:25] There might or might not be, the description of the issue just has some similar words ;) [15:25] (don't understand the details, myself) [15:31] dmart, yeah [15:32] Was that another alignment fault, or something else? [15:35] ogra, about? [15:35] apw, indeed [15:35] bug #458537 [15:35] Launchpad bug 458537 in linux-fsl-imx51 "[armel imx51] hibernate does not work" [High,Triaged] https://launchpad.net/bugs/458537 [15:36] the current states of the tasks make little sense to me. if the kernel is correctly reporting that hibernate is not supported then if devkit-power says it is available then its broken [15:36] so it seems to me its tasks should be open for that but, or perhaps anohter bug filed (i guess) [15:37] and the kernel is doing the right thing, its reporting it not available as its not going to be there as its not supported by the platform [15:37] apw, its all solved ... devkit doesnt expose hibernate to the gui anymore [15:37] so i would normally close the kernel tasks invalid, but you've said you want themj open [15:38] so ... how do we resolve that [15:38] and suspend/resume works too as of today, so all these bugs cvan be closed. the suspend/resume bug is missing one final test with the uboot bootloader though [15:39] well, i'D like to still have a reminder to talk to FSL if they cant implement it somehow ... hibernate is a pure kernel thing, there is no HW changes or whatnot required [15:39] dmart, not sure, but its another one of those stability is lacking bugs :-/ [15:39] apw, so it would be nice if they added code to support it [15:40] ogra, launchpad doesn't allow us to do what i would like to do, which is close karmic and lucid and leave M open as a reminder ... hrm [15:40] apw, and it would be nice to have a bug to püoint them to ... but if you need it closed, close it :) [15:41] the release team wants it closed as its not a problem per-see [15:41] why does the release team care for iuntargeted bugs ? [15:41]