**** BEGIN LOGGING AT Mon Jan 25 02:59:57 2010 Jan 25 07:08:11 I have a question about programs Jan 25 07:08:38 If I download the source to pd extended will it build on u-arm? Jan 25 07:09:00 * persia checks Jan 25 07:09:13 Sorry I'm seriously daft Jan 25 07:10:14 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 Jan 25 07:10:34 Well, puredata seems to be built. I'm not sure why pd-extended wouldn't. Jan 25 07:10:46 But since I'm not finding pd-extended available, I'm guessing it's not already done. Jan 25 07:10:51 So no issues on arm arch Jan 25 07:10:59 (but I also don't see it in the build failure report, so I presume it's out-of-archive) Jan 25 07:11:14 There's source and it builds on ubuntu on my desktop Jan 25 07:11:29 Which Ubuntu source package? Jan 25 07:11:35 But I'm wondering if it'll build on an sbc Im getting Jan 25 07:11:47 9.10 I think Jan 25 07:12:46 Oh the package sorry I'm real slow tonite Jan 25 07:13:17 Well, http://qa.ubuntuwire.com/ftbfs/karmic.html is the fail-to-build-from-source report for 9.10 Jan 25 07:13:49 So, if puredata needs a package there, it ought fail, but it appears puredata succeeded, so I suspect it would work. Jan 25 07:14:20 http://puredata.info/downloads Jan 25 07:14:30 Ok cool Jan 25 07:14:58 So the whole portability q I keep seein on this hardware forum is about other stuff Jan 25 07:15:31 I guess I was wondering what issues I might run into just using make etc on the source on an arm setup Jan 25 07:15:34 I thought I remembered a pd-extended source package, but I'm not finding it now. Jan 25 07:16:22 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. Jan 25 07:16:28 I believe the karmic toolchain to be mostly clean. Jan 25 07:16:37 Groovy Jan 25 07:17:10 Really I just need pd and the gem library Jan 25 07:17:17 Sounds solid now Jan 25 07:17:53 pd and gem should be available with apt-get Jan 25 07:18:05 Nice Jan 25 07:18:16 Depending on your kernel, you may end up with issues at lower levels, but at the high levels, all is good. Jan 25 07:18:27 Making an effects box? Jan 25 07:18:51 Actually just trying to get a smaller computer for generative music and video stuff Jan 25 07:19:13 Also I preordered a pandora Jan 25 07:19:39 I figure in the end I'll rock pandora but maybe angstrom if it wows me Jan 25 07:21:26 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. Jan 25 07:21:45 Pandora has enough for what I'm gunna rock Jan 25 07:21:50 Cool! Jan 25 07:22:03 Usually our sound guys push the faders up too much anyway Jan 25 07:22:05 Hehe Jan 25 07:22:24 heh. Then it doesn't matter if you have perfect DA converters :) Jan 25 07:22:54 Yeah... This has only made me more excited for my open pandora Jan 25 07:26:07 Thanks a bunch for helping Jan 25 07:26:37 I was pretty sure it would just build but I won't be certain till my hardware is here Jan 25 11:07:06 hmm, so all plymouth error messages are gone with my new babbage install Jan 25 11:07:18 \m/ Jan 25 11:07:40 reinstall from A2 and dist-upgrade seems to have worked fine Jan 25 11:07:50 i even have suspend/resume working properly Jan 25 11:08:03 And is plymouth actually running? Jan 25 11:08:15 i dont think so, let me check Jan 25 11:08:26 the console fonts change during boot so it might be Jan 25 11:08:36 i.e. i see some bold parts in the fsck output Jan 25 11:09:13 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) Jan 25 11:09:53 hmm, should i see a logfile or something ? Jan 25 11:10:02 i know there is a plymouth-log process usually Jan 25 11:10:18 No idea, sorry. Jan 25 11:10:24 well, i'll reboot Jan 25 11:19:04 i dont see any splash ... but Jan 25 11:19:31 i can run plymouthd manually and run plymouth --show-splash and see a moving bar at the bottom of the screen on tty8 Jan 25 11:19:44 its odd that X is on tty1 now :( Jan 25 11:20:04 makes my finger memory unhappy :) Jan 25 11:22:09 It makes for no VT switch, which is apparently both faster and more appealing. Jan 25 11:22:24 But I'm glad to hear it works. Jan 25 11:23:19 well, seems plymouthd defaults to tty8 Jan 25 11:23:42 so if it doesnt do a vt switch and stays on vt1 there is indeed no way for me to see it Jan 25 11:25:33 hrm. Jan 25 12:07:19 * ogra wonders why motd tells him he can update 285 packages Jan 25 12:07:27 i just did a dist-upgrade Jan 25 12:08:02 asac, so plymouth dies because of the console comdline option we use Jan 25 12:09:53 The console command line? The kernel command line? Jan 25 12:10:04 yes Jan 25 12:10:22 And if we use a different one, it works? Jan 25 12:10:48 the "moutall: could not connect to plymouth" goes away if i remove "console=ttymcx0,115200 console=tty0" from the cmdline Jan 25 12:11:05 And where does console end up? Jan 25 12:11:08 also the plymouth-log error Jan 25 12:11:12 tty0 Jan 25 12:11:19 as its supposed to Jan 25 12:11:45 the A2 install i had didnt set console, now that i switched to uboot i have a console entry Jan 25 12:11:46 Well then, that sounds like a reasonable thing to fix. Jan 25 12:12:01 if i remove it and make it look like the redboot line we install it works Jan 25 12:12:14 Cool! Jan 25 12:12:21 That's fancy demo stuff, there. Jan 25 12:12:24 as soon as i enforce a tty by using console= it breaks Jan 25 12:15:06 hmm, let me try tty8 ... probably plmouth runs already but i dont see it Jan 25 12:15:51 285 packages can be updated. Jan 25 12:15:51 0 updates are security updates. Jan 25 12:15:53 GRRR Jan 25 12:15:56 liar !!! Jan 25 12:16:22 Run update-motd to make it go away. Jan 25 12:16:37 ogra@babbage2:~$ sudo update-motd Jan 25 12:16:37 sudo: update-motd: command not found Jan 25 12:18:49 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. Jan 25 12:19:01 Last time I found a bug it got fixed within two days. Jan 25 12:20:06 not so pressing now Jan 25 12:20:19 * ogra is more intrested in seeing plymoutho Jan 25 12:20:23 -o Jan 25 12:20:26 heh Jan 25 12:21:57 so tt8 quitens down even more but doesnt make plymouth work Jan 25 12:22:37 * ogra looks at /usr/share/initramfs-tools/scripts/init-top/plymouth Jan 25 12:22:46 printf '\033[?25l' > /dev/tty7 Jan 25 12:22:46 /sbin/plymouthd --mode=boot --pid-file=/dev/.initramfs/plymouth.pid Jan 25 12:22:46 /bin/plymouth --show-splash Jan 25 12:22:48 hmm Jan 25 12:23:02 whats that printf ? a clear command ? Jan 25 12:23:21 show (or hide) cursor Jan 25 12:23:25 * ogra tries console=tty7 Jan 25 12:25:34 nope Jan 25 12:25:41 doesnt work either Jan 25 12:25:46 and i see a cursor :) Jan 25 12:29:43 GAH ! Jan 25 12:29:45 my X crashed Jan 25 12:31:59 You didn't really need that, did you? Jan 25 12:32:20 printf '\033[?25l' > /dev/tty works in a xterm here :-) Jan 25 12:32:33 * ogra slaps persia with a wet towel Jan 25 12:33:43 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= Jan 25 12:34:43 Does Alt+Fn7 not switch for you? Jan 25 12:34:52 Or can you change the config? Jan 25 12:34:57 sure it does, but way to late :) Jan 25 12:35:30 You clearly need to find some way to slow down the boot :) Jan 25 12:35:35 ogra@babbage2:~$ man plymouthd Jan 25 12:35:35 No manual entry for plymouthd Jan 25 12:35:37 BOOO ! Jan 25 12:35:47 ogra@babbage2:~$ man plymouth Jan 25 12:35:47 No manual entry for plymouth Jan 25 12:35:49 BOO++ Jan 25 12:36:14 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. Jan 25 12:36:20 (and this annoys users, like you) Jan 25 12:44:58 dmart, you around? Jan 25 12:45:00 had to join first ;) Jan 25 12:45:09 NCommander, hi Jan 25 12:45:36 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 Jan 25 12:45:40 s/ARM/Dove/g Jan 25 12:45:46 sure Jan 25 12:46:16 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 Jan 25 12:48:07 dmart, (I might be mistaken on this part, I'm not very familiar with kernel code handling alignment) Jan 25 12:50:10 I think that's normal? User: vldr *boom* -> kernel: fault kandler -> emulate unaligned vldr -> return to userspace following the faulted instruction Jan 25 12:50:20 s/kandler/handler Jan 25 12:50:40 dmart, right, based on how the kernel handles alignment faults, that was my understanding as well Jan 25 12:51:08 dmart, the problem then is impossible to fix in kernelspace because the kernel doesn't vet each individual instruction Jan 25 12:51:36 (or at leas tin this portion of kernel space) Jan 25 12:52:23 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) Jan 25 12:52:40 not sure which one is faster Jan 25 12:52:58 (I'm guessing returning to ARM mode is going to be faster, but I wanted to run that by you) Jan 25 12:57:27 dmart: you can also reply to me ;) Jan 25 12:57:31 ah there he is again Jan 25 12:57:44 nm Jan 25 12:58:20 ugh, sorry Jan 25 12:58:22 router decided a lovely time to HCF Jan 25 12:58:24 What was the last thing that you saw from me? Jan 25 12:58:26 Time can7t reach him, but timeouts can :) Jan 25 12:58:42 [21:53] (I'm guessing returning to ARM mode is going to be faster, but I wanted to run that by you) Jan 25 12:59:00 persia, that sounds like it was from a song. Jan 25 12:59:10 was there a response :-) Jan 25 12:59:24 No. Jan 25 12:59:55 ok, the mount error on imx51 boot seems to definately be bootchart Jan 25 13:00:03 * ogra removes it Jan 25 13:00:06 * NCommander is looking at his GCC theory Jan 25 13:00:45 mount -t proc none $JAIL/proc Jan 25 13:00:50 hmm, can that be none ? Jan 25 13:00:56 ogra, yes Jan 25 13:01:00 * NCommander uses that all the time Jan 25 13:01:01 * ogra always thought it *has* to be proc Jan 25 13:01:05 Can be any string. It's not read. Jan 25 13:01:13 * persia usually uses "proc" Jan 25 13:01:14 ok Jan 25 13:01:17 me too Jan 25 13:01:33 * NCommander usually uses none or its purpose Jan 25 13:01:49 proc-hardy on /home/chroots/hardy-i386-android/proc type proc (rw) Jan 25 13:02:45 That's why I use "proc", as the context is obvious by $PS1 Jan 25 13:02:54 hrm, and it wasnt the error anyway Jan 25 13:03:20 ogra@babbage2:~$ grep mount /usr/share/initramfs-tools/scripts/init-top/* Jan 25 13:03:20 /usr/share/initramfs-tools/scripts/init-top/bootchart:mount -t proc none $JAIL/proc Jan 25 13:03:20 ogra@babbage2:~$ Jan 25 13:03:28 but thats the only mount call in init-top Jan 25 13:03:30 weird Jan 25 13:03:38 * ogra checks the init script itself Jan 25 13:04:21 hrm Jan 25 13:04:22 ok Jan 25 13:05:18 aha Jan 25 13:05:22 mount -t tmpfs -o mode=0755 none /dev Jan 25 13:05:23 hmm Jan 25 13:07:45 Did you want $JAIL/dev ? Jan 25 13:07:53 no Jan 25 13:07:58 thats what bootchart wanted Jan 25 13:08:05 which i removed already Jan 25 13:08:10 that line is from init Jan 25 13:08:13 Ugh. Jan 25 13:08:17 if ! mount -t devtmpfs -o mode=0755 none /dev; then Jan 25 13:08:17 mount -t tmpfs -o mode=0755 none /dev Jan 25 13:08:17 mknod -m 0600 /dev/console c 5 1 Jan 25 13:08:17 mknod /dev/null c 1 3 Jan 25 13:08:17 fi Jan 25 13:08:21 to be precise Jan 25 13:11:39 hmm, is devtmpfs a .32 feature we miss in .31 ? Jan 25 13:13:39 I thought it was very new: http://blog.steve.org.uk/we_have_to_be_ready_to_do_anything__do_you_hear_me_.html Jan 25 13:14:06 yeah Jan 25 13:14:22 well, it was there for a while afaik but experimental Jan 25 13:14:53 Seems first introduced April 2009. Jan 25 13:14:58 right Jan 25 13:15:16 So how isn't this devfs, which everyone decided was bad? Jan 25 13:15:22 * persia is confused Jan 25 13:15:27 no idea Jan 25 13:15:34 i just want the error to go away :P Jan 25 13:15:54 Well, get the kernel built with devtmpfs then. Jan 25 13:16:05 ogra@babbage2:~$ grep DEVTMPFS /boot/config-2.6.31-602-imx51 Jan 25 13:16:05 ogra@babbage2:~$ Jan 25 13:16:16 seems we dont even have the option Jan 25 13:16:17 Does N appear with that? Jan 25 13:16:27 N ? Jan 25 13:16:31 Hrm. Then let's drop it from userspace. Jan 25 13:16:40 its in init Jan 25 13:16:44 Stuff neither selected nor modules, especially stuff that only shows up in submenus. Jan 25 13:16:49 and udev uses it massively Jan 25 13:17:03 and beyond that it slows down booting to not have it with new udev Jan 25 13:17:06 Then lets add it to the backport list :) Jan 25 13:17:12 right Jan 25 13:17:20 very high up Jan 25 13:17:53 where is cooloney when one needs him :P Jan 25 13:18:00 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) Jan 25 13:19:35 if you use devtmpfs the initial device tree gets directly populated by the kernel Jan 25 13:19:44 Right. Jan 25 13:19:44 else it will be done by udev scripts Jan 25 13:19:48 Right. Jan 25 13:19:51 which are slower indeed Jan 25 13:19:55 * persia used to use devfs extensively Jan 25 13:20:25 looking at some benchmarks google finds for me it seems it removes about 2sec Jan 25 13:20:27 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. Jan 25 13:21:31 NCommander, sorry, I was away for a bit. What exactly do you mean by "32 vmovs"? Jan 25 13:22:09 dmart, 32 vmov instructions to emulate vldr Jan 25 13:22:35 yes, but why 32? (I may just be missing the point) Jan 25 13:22:54 NCommander, not 32, it could be 2 vmov for vldr or 1 Jan 25 13:23:21 2 vmov for vldr of double word, 1 vmov for vldr of single word Jan 25 13:23:39 32 vmov listed there are for quick expansion Jan 25 13:24:57 Yes, I'd expect ldr+ldr+vmov (double) or ldr+vmov (single) Jan 25 13:25:23 dmart, you aware of the dove issue right? Jan 25 13:25:29 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? Jan 25 13:25:43 ericm_, oops, misread the code :-) Jan 25 13:26:01 * NCommander has not played much with handwritten VFP ASM Jan 25 13:26:09 NCommander, I was upset the first time as well Jan 25 13:26:12 dmart, the fault never comes, and the board hangs. Jan 25 13:26:54 Ah... I see. So we need the userspace code not to do that? Jan 25 13:26:57 NCommander, with a latest apt-get upgrade, it looks the system freeze issue has gone, so far no freeze Jan 25 13:27:35 dmart, the issue happens only when VLDR is executed in Thumb2 mode, an incorrect alignment fault is generated Jan 25 13:27:52 dmart, pretty much, but we have vldr's all over the place, my first theory just crashed and burned Jan 25 13:28:08 NCommander, that's what I want to say Jan 25 13:28:41 ericm_, I'm going to also see if I can isolate what's causing our counters to run backwards on Dove Jan 25 13:28:53 since it still happens with X0. Jan 25 13:29:03 That would be very useful to find out. Jan 25 13:29:28 NCommander, and asac told me the python bug invokes the system freeze so not clear if it's caused by this VLDR bug though Jan 25 13:29:35 Do you know where the problem vldrs are coming from in userspace, or are they just everywhere? Jan 25 13:29:46 but yes, the apt-get showing negative could be related to this Jan 25 13:30:00 atm our dove images work Jan 25 13:30:08 so its not really everywhere Jan 25 13:30:27 for me (without knowning) it just feels like dove doesnt like if something "irregular" happens Jan 25 13:30:30 like a crash etc. Jan 25 13:30:34 dmart, Marvell has a patch to workaround that bug Jan 25 13:30:35 if all is fine things seem to work Jan 25 13:30:49 dmart, but we are doubting that fixes all the odds Jan 25 13:31:01 ericm_: where is that patch? Jan 25 13:31:09 already in our kernel? Jan 25 13:31:25 asac_, yes Jan 25 13:31:28 asac_, wait Jan 25 13:31:48 http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=1ccfc4f93a746849521afba13ea62aac119c43bd Jan 25 13:31:52 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 Jan 25 13:31:56 ericm_: is that in the archive yet? Jan 25 13:32:13 asac_, already since several weeks ago Jan 25 13:32:24 dmart, we've had the issue since before the vldr patch went in :-/ Jan 25 13:32:27 right. so we dont doubut ... we _know_ that there are still issues left Jan 25 13:32:45 dmart, I agree Jan 25 13:33:02 OK, sounds like it's worth digging into the apt-get issue, since something's definitely going wrong reliably in there Jan 25 13:33:13 NCommander, but those are different issues - without vldr patch - we know those unalignment faults won't be handled Jan 25 13:33:29 not sure though if this ever happens on imx51 Jan 25 13:33:39 the negative counter issue Jan 25 13:34:38 ericm_, doesn't happen on imx51 Jan 25 13:34:52 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. Jan 25 13:35:12 * ogra files bug 512321 Jan 25 13:35:14 Launchpad bug 512321 in linux-fsl-imx51 "please backport devtmpfs to the lucid linux-imx51 kernel tree" [High,New] https://launchpad.net/bugs/512321 Jan 25 13:35:14 dmart, let me check Jan 25 13:35:41 If you have a .o file handy, it'd be interesting to see it. Jan 25 13:36:15 dmart, I'm fairly sure its not no-op'ed since the vldr patch fixed Xorg Jan 25 13:37:21 Agreed; it's probably working, though it depends on the compiler behaviour. Jan 25 13:37:21 dmart, they are indeed expanded Jan 25 13:37:39 a long list of vmov + b, ugly but should work Jan 25 13:39:36 Do we have a known, small, sequence of assembly that generates the fault? Jan 25 13:40:09 persia, just write a simple test.c with double - I'm pretty sure a VLDR instruction will be generated Jan 25 13:40:35 * persia doesn't have HW, so wouldn't know if it caused the issue Jan 25 13:40:47 printf("%d", (int)((double)a / (double)b)) Jan 25 13:40:50 ericm_ does vldr _always_ fault in Thumb-2? Or is it on occasional anomaly? Jan 25 13:40:59 dmart, always Jan 25 13:41:00 But I'd think working from a known, small, test case would be easier than working from the entirety of userspace. Jan 25 13:41:14 dmart, and Dove X0 fixes this issue Jan 25 13:41:23 ericm_, it does? Jan 25 13:41:38 NCommander, no alignment fault ever been seen Jan 25 13:41:57 NCommander, actually "echo 3 > /proc/cpu/alignment" can reveal all alignment faults on your console Jan 25 13:42:06 NCommander, never seen a single on X0 Jan 25 13:42:27 ericm_: does import uno hang on X0 ? Jan 25 13:42:37 * persia wonders more if it's worth fixing in SW if it only appears for some prerelease dev boards Jan 25 13:42:47 asac_, no X0 at hands Jan 25 13:42:53 ^- persia Jan 25 13:42:58 asac_, will have to come to Marvell office for that Jan 25 13:43:07 ericm_: weren't there marvell folks in this channel at some point ;)? Jan 25 13:43:18 can we get them back? Jan 25 13:43:44 asac_, I think so - but probably not this time :) Jan 25 13:44:31 NCommander, did you ever finish your fix for likewise-open ? Jan 25 13:45:00 ogra, its unfortunately non-trivial. It gets through 95% of the modules before it blows its brains on the last one Jan 25 13:45:23 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 Jan 25 13:45:35 or we get all new hardware Jan 25 13:45:36 ogra, I know how to fix the last one, but the proper technique is alluding me Jan 25 13:45:38 thats ok too i guess Jan 25 13:45:57 asac_: Consider my statement a suggestion for option (b) :) Jan 25 13:46:04 yeah Jan 25 13:46:12 i will discuss this with david today for sure Jan 25 13:46:37 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 Jan 25 13:46:49 ack++ Jan 25 13:46:49 *remaining Jan 25 13:46:50 please do Jan 25 13:47:06 ogra, I take it we got a ping from the server team to look at this? Jan 25 13:47:12 NCommander, nope Jan 25 13:47:14 oh Jan 25 13:47:21 NCommander, it shows up on the FTBFS list Jan 25 13:47:32 asac_, NCommander, are we still going to support Z0 BTW? Jan 25 13:47:40 i doubt it Jan 25 13:47:44 ericm_, we made the call in lucid to drop it Jan 25 13:47:48 for now i want Y1 to work Jan 25 13:47:55 NCommander, ok Jan 25 13:47:55 ericm_, the kernel and the bootloader are fubar'ed for it Jan 25 13:48:02 NCommander, its their package, so its fine if they do the rest, but you put work into they should know about Jan 25 13:53:45 ericm_, the dove patch does this: addr &= ~3; __get_user(val, (u32 *)addr); Jan 25 13:54:10 This won't correctly emulate a misaligned load? Jan 25 13:54:28 Or is the problem that we fault on an aligned vldr? Jan 25 13:54:52 dmart, the issue they mentioned is only about VLDR in Thumb2 mode Jan 25 13:55:18 dmart, I guess the problem is even if it's aligned VLDR, the fault happens anyway Jan 25 13:55:40 for an unaligned VLDR, the fault is expected to happen right? Jan 25 13:56:15 Yes Jan 25 13:56:17 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. Jan 25 13:56:24 Mmm.... actually doubt this can correctly handle those unaligned VLDR Jan 25 13:57:00 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. Jan 25 13:57:24 dmart, indeed - esp. since the compiler is smart enough to get rid of this Jan 25 13:59:58 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... Jan 25 14:00:00 ...problems on imx51 if we hit that case though. Jan 25 14:00:56 dmart, yet I expect the support for such faults should be there in the kernel, lemme check Jan 25 14:01:16 I think the correct think in the patch would if if(addr & 3) goto fault; Jan 25 14:01:54 * NCommander hrms Jan 25 14:02:09 I just copied in an apt-get from karmic into a lucid chroot, and I still get backwards running counters :-/ Jan 25 14:02:47 dmart, I agree - currently the vldr workaround is placed before other unalignment fault handling code Jan 25 14:03:22 dmart, so your proposal will lead to the VLDR workaround to fix only those aligned faults Jan 25 14:04:15 ...which I think matches the imx51 behaviour Jan 25 14:04:20 dmart, a good catch - will let Marvell guys know this Jan 25 14:04:49 It's only a problem for wrong userspace code, so it's more an anomaly than a full on bug Jan 25 14:04:54 NCommander, so that doesn't seems to be related to the VLDR issue Jan 25 14:05:07 NCommander, maybe it's in libc or somewhere? Jan 25 14:05:22 dmart, or one of APT's support libraries Jan 25 14:06:08 Hmmm, libutil1, libstdc++6, eglibc (libc6, libm6, libdl2) Jan 25 14:06:23 dmart, theres a libapt-pkg* I didn't replace Jan 25 14:06:29 let me just fully install the karmic version Jan 25 14:06:58 * ericm_ needs some sleep Jan 25 14:07:05 'night ericm_ ... thx Jan 25 14:07:11 Oops, yes, libapt-pkg-libc6 Jan 25 14:08:17 Thanks. I think the fixup in do_alignment_thumb_vldr is otherwise correct. Jan 25 14:08:22 dmart, yeah, that fixed it Jan 25 14:08:22 hrm Jan 25 14:08:35 Hmmm, so we know which lib it's in Jan 25 14:09:33 Cool Jan 25 14:09:33 -er- well, it's the same set (deps of libapt-pkg-libc6) Jan 25 14:09:40 dmart, actually, its the HTTP handler of APT Jan 25 14:09:48 dmart, if I use FTP, the problem goes poof Jan 25 14:10:07 Oh right. Is that dlopen'd ? I noticed libdl is linked in there. Jan 25 14:10:10 -rwxr-xr-x 1 root root 43K Dec 23 16:28 /usr/lib/apt/methods/http Jan 25 14:10:31 Right Jan 25 14:11:17 Fetched -656298B in 3s (-191066B/s) - this is just getting annoying :-/ Jan 25 14:11:34 unless you can make the clock go backwards too :P Jan 25 14:12:17 It is possible to backtract from those printfs and see where the negative answers start to appear...? Jan 25 14:13:14 dmart, looking Jan 25 14:21:43 dmart, ugh, its a twisty set of includes, and I'm not sure specifically where's going bust Jan 25 14:23:00 HMM Jan 25 14:23:05 s/HMM/hmm/ Jan 25 14:26:08 Z BG Jan 25 14:26:17 argh, wrong window again Jan 25 14:28:53 Are there any other methods that we could try easily? Jan 25 14:29:05 dmart, well, I found the code formatter Jan 25 14:29:13 dmart, and I'm testing to see if the number going into that is value or not Jan 25 14:29:18 at least gives me an idea of where to look Jan 25 14:30:07 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... Jan 25 14:53:41 contrib/mmap.cc:246: internal compiler error: Illegal instruction Jan 25 14:53:48 * NCommander thunks his head on the desk Jan 25 14:53:51 ARGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Jan 25 15:02:03 nice, as suspected dove live image now boots up fine :) Jan 25 15:02:15 and plymouth appears to be working nicely as well Jan 25 15:02:42 doh, gnome-panel just died though Jan 25 15:17:31 plars, "as suspected": what was the fix? Jan 25 15:18:30 NCommander, were you building on Dove there? Jan 25 15:19:10 dmart: there was a new build of python on Friday, I'm not sure what all is different off the top of my head Jan 25 15:19:29 ok, thanks Jan 25 15:19:31 dmart: but asac suspected it would help, so I tried with it on Friday and could no longer get pybootchartgui to crash Jan 25 15:19:41 dmart: importing uno.py still hangs though Jan 25 15:20:15 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 Jan 25 15:20:39 Is there any relationship to the OOo bug there? I remember uno and exceptions being involved, but can't remember all the background now. Jan 25 15:24:10 dmart: asac seemed to be indicating he thought there was some connection Jan 25 15:25:05 There might or might not be, the description of the issue just has some similar words ;) Jan 25 15:25:19 (don't understand the details, myself) Jan 25 15:31:38 dmart, yeah Jan 25 15:32:09 Was that another alignment fault, or something else? Jan 25 15:35:27 ogra, about? Jan 25 15:35:37 apw, indeed Jan 25 15:35:56 bug #458537 Jan 25 15:35:57 Launchpad bug 458537 in linux-fsl-imx51 "[armel imx51] hibernate does not work" [High,Triaged] https://launchpad.net/bugs/458537 Jan 25 15:36:29 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 Jan 25 15:36:56 so it seems to me its tasks should be open for that but, or perhaps anohter bug filed (i guess) Jan 25 15:37:26 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 Jan 25 15:37:32 apw, its all solved ... devkit doesnt expose hibernate to the gui anymore Jan 25 15:37:59 so i would normally close the kernel tasks invalid, but you've said you want themj open Jan 25 15:38:13 so ... how do we resolve that Jan 25 15:38:19 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 Jan 25 15:39:07 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 Jan 25 15:39:24 dmart, not sure, but its another one of those stability is lacking bugs :-/ Jan 25 15:39:31 apw, so it would be nice if they added code to support it Jan 25 15:40:42 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 Jan 25 15:40:45 apw, and it would be nice to have a bug to püoint them to ... but if you need it closed, close it :) Jan 25 15:41:04 the release team wants it closed as its not a problem per-see Jan 25 15:41:20 why does the release team care for iuntargeted bugs ? Jan 25 15:41:28 it is targetted Jan 25 15:41:31 its a general problem of that kernel Jan 25 15:41:39 but its not up to us to fix it Jan 25 15:41:49 i thought i closed all targets Jan 25 15:42:08 oh Jan 25 15:42:11 the kernel is still targetted to lucid Jan 25 15:42:15 i removed the milestones :) Jan 25 15:42:38 cant we un-target and leave it as a bug in the package Jan 25 15:42:52 if you can untarget it yes, no idea how to do that Jan 25 15:42:53 hmm, doesnt seem like Jan 25 15:43:01 yeah, nothing in the UI Jan 25 15:43:20 just close it then Jan 25 15:43:21 and its current state is confused, the linux is targetted and devicekit-power not Jan 25 15:43:32 well, devkit works fine Jan 25 15:43:34 and that has three entries, karmic/lucid/ and what would be lucid Jan 25 15:43:39 the comments arent up to date Jan 25 15:43:41 and linux only has two ... Jan 25 15:43:46 which doesn't seem possible to my mind :) Jan 25 15:44:05 yeah, its weird Jan 25 15:44:17 just close the tasks and dont worry Jan 25 15:44:59 i'm happy tracking the issue on my TODO list on my whiteboard in the office instead :) Jan 25 15:45:02 ogra, thanks ... i dispare with launchpad sometimes Jan 25 15:46:39 apw, btw, bug 512321 is untriaged yet (if you are doing bugwork) Jan 25 15:46:40 Launchpad bug 512321 in linux-fsl-imx51 "please backport devtmpfs to the lucid linux-imx51 kernel tree" [High,New] https://launchpad.net/bugs/512321 Jan 25 15:46:58 apw, i wonder how hard it is to backport devtmpfs here Jan 25 15:47:09 * apw wonders why we need it Jan 25 15:47:11 the patch didnt look to big Jan 25 15:47:18 bootspeed ? Jan 25 15:47:56 as i understand booting gets slowed down if udev scripts run instead of having a devtmpfs pre-populated Jan 25 15:48:45 and i'm not sure if any userspace apps wont have a requirement for it too before lucid goes final Jan 25 15:50:37 ogra, thanks for the heads up Jan 25 15:50:42 :) Jan 25 16:12:53 wohoo, asac is back Jan 25 16:46:03 plymouth works !! Jan 25 16:46:05 \o/ Jan 25 17:04:31 ogra: i am back ;) Jan 25 17:04:35 not sure for how long though Jan 25 17:04:44 something is fishy with my server Jan 25 17:04:56 even irssi doesnt autojoin all the channels anymore ;) Jan 25 17:05:16 ogra: nice ... what was the prob with plymouth Jan 25 17:05:17 ? Jan 25 17:18:34 asac, it defaults to the text plugin Jan 25 17:19:11 i dont know why yet, but running plymouth-set-default-theme ubuntu-logo and re-rolling the initramfs fixes it Jan 25 17:19:20 interesting Jan 25 17:19:40 its definately a bug that it isnt set by default Jan 25 17:19:49 what is that text plugin? wasnt plymouth done to not have text anymore? Jan 25 17:19:50 but technically plymouth works as it should Jan 25 17:20:09 the text plugin looks like normal console ... just without a cursor Jan 25 17:20:24 i noticed i get the fsck output in bold Jan 25 17:20:36 ah. ok Jan 25 17:20:38 so it seems to highlight a bunch of text Jan 25 17:21:32 i have to find out why /lib/plymouth/themes/default.plymouth doesnt point to the right theme though ... but i guess i'll have to wait for Keybuk for that Jan 25 17:21:39 no clue what sets it Jan 25 17:21:53 asac_, did david talk to you about uboot ? Jan 25 17:22:03 yes Jan 25 17:22:09 good Jan 25 17:34:43 bye asac :) Jan 25 17:35:04 armin76: bye? Jan 25 17:35:07 :) Jan 25 17:35:26 asac_: You're dead. Does that mean you'll be coming back soon? Jan 25 17:36:37 let me check Jan 25 17:39:41 ogra: looks like flashkernel is failing again on ubiquity. Last time, that seemed to be related to an oversized initrd, but I don't think that's the problem here. Any ideas? Jan 25 17:41:11 plars: output log? Jan 25 17:41:21 persia: dead due to what? Jan 25 17:41:52 [02:28] * asac has quit (Read error: 110 (Connection timed out)) Jan 25 17:42:01 persia: I have the .crash file from ubiquity, but it's a known issue that it fails silently when flashkernel fails Jan 25 17:42:29 plars: Have you tried adding set -x to flash-kernel, and then calling it manually? Jan 25 17:42:36 (this should give you some output) Jan 25 17:42:54 persia: I'll try that Jan 25 17:45:03 aha, I think I might see the problem Jan 25 17:45:41 Cool. What's the problem? Jan 25 17:48:22 persia: the actual initrd and vmlinuz are missing from the squashfs Jan 25 17:48:33 persia: the symlinks are there, but no file that they link to Jan 25 17:48:38 Aha! Jan 25 17:49:08 Because we don't stuff them into the image because we're using the silly filesystemless kernel method. Jan 25 17:49:37 Which means that we need to modify debian-cd to actually place the artifacts in place correctly. Jan 25 17:49:54 And then, as long as we continue not to mount the filesystem, we end up wtih duplicates in the images. Jan 25 17:50:05 But that's not *too* much extra space. Jan 25 17:56:49 hmm ? Jan 25 17:56:56 sure we put them into the image Jan 25 17:57:10 Then why isn't plars seeing them? Jan 25 17:57:23 ogra: mount the squashfs from today's image Jan 25 17:57:31 ogra@osiris:~$ ls /media/4B4D-D0D4/casper/ Jan 25 17:57:31 filesystem.manifest filesystem.manifest-desktop filesystem.size filesystem.squashfs initrd.lz vmlinuz Jan 25 17:57:46 they arent in the squashfs Jan 25 17:57:55 ogra: shouldn't they be? Jan 25 17:57:57 and are not supposed to be ever Jan 25 17:58:00 no Jan 25 17:58:09 on no image we build Jan 25 17:58:16 ogra: the result is that in /boot on the booted image, it doesn't find them Jan 25 17:58:18 (including non arm) Jan 25 17:58:38 do you have the exact output ? Jan 25 17:58:39 and flash-kernel is complaining that it can't find them in / or /boot Jan 25 17:58:55 ogra: of what, flash-kernel? Jan 25 17:59:01 Oh. Jan 25 17:59:11 ubiquity is supposed to copy vmlinuz to /boot before flash-kernel runs Jan 25 17:59:15 So the issue isn't in debian-cd, it's in base-installer Jan 25 17:59:24 no, its in ubiquity Jan 25 17:59:28 Because we're using flash-kernel, we're probably not copying the files to /boot Jan 25 17:59:33 not sure if base-installer uses that too Jan 25 17:59:34 No, ubiquity doesn't do that. Jan 25 17:59:41 ubiquity just controls base-installer, which does that. Jan 25 17:59:42 sure Jan 25 17:59:49 * persia discovered this when making lpia work Jan 25 17:59:53 its somewhere in install.py Jan 25 18:00:05 It moved? Jan 25 18:00:07 its a while that i looked last Jan 25 18:00:15 but laszt time it was in there Jan 25 18:00:16 More recently than I :) Jan 25 18:00:22 * persia last looked in intrepid Jan 25 18:00:23 well, around karmic Jan 25 18:00:32 i havent thouched ubiquity in lucid yet Jan 25 18:00:47 but in any case there should be nothing in /boot Jan 25 18:00:51 to save space Jan 25 18:01:01 else you would duplicate the kernel Jan 25 18:01:20 Then it needs to copy from /cdrom Jan 25 18:01:26 there is code that copies from /cdrom/casper to /boot Jan 25 18:01:28 right Jan 25 18:01:43 Personally, I think we ought have the bootloader mount boot, and not bother with flash-kernel. Does this really still not work? Jan 25 18:01:55 not with redboot Jan 25 18:02:05 and definately not with our image design Jan 25 18:02:12 Works with my redboot. Would me asking for source help you? Jan 25 18:02:15 (would require a separate /boot partition) Jan 25 18:02:24 not really Jan 25 18:02:30 That's what I thought. Jan 25 18:02:41 its one of the reasone we will probably not switch to uboot for Jan 25 18:02:46 *reasons Jan 25 18:02:55 (the requirement of /boot) Jan 25 18:03:25 Well, you don't really need /boot for the installer. Jan 25 18:03:29 Just load the kernel off / Jan 25 18:03:42 And then put it in a /boot partition during install. Jan 25 18:03:43 ogra: what i would like to see is a short list of issues and features we lack so we can forward that Jan 25 18:03:51 then we are off the hook Jan 25 18:03:53 i guess Jan 25 18:03:57 persia, well, the /boot partzition has to live on the SD Jan 25 18:04:06 No it doesn't. Jan 25 18:04:19 Or rather. Why? Jan 25 18:04:20 asac_, yes, i assembled that on the weekend as i said, just need to formulate it a bit better Jan 25 18:04:33 persia, the babbage can only boot off the first SD Jan 25 18:04:38 ogra: you can just send it to me and i can fix the wording if you want ;) Jan 25 18:04:42 persia, no matter which bootloader you use Jan 25 18:04:58 just thinking you would be happy to get that off your plate ;) Jan 25 18:05:08 It can't boot of SATA? Jan 25 18:05:13 s/of/off/ Jan 25 18:05:27 "it cant do nothing" Jan 25 18:05:38 persia, it can do exactly as much as redboot can Jan 25 18:05:40 My. That's limiting. Jan 25 18:05:47 Well, for some redboots. Jan 25 18:05:53 plus it can read fat and ext2 partitons Jan 25 18:06:04 comparing to the babbge redboot indeed Jan 25 18:06:05 Like I said, I have a redboot that boots from two alternate locations, and mounts a partition for one of those boots. Jan 25 18:06:09 (from some devices) Jan 25 18:06:24 yeah, from some SDs Jan 25 18:06:31 if you are lucky ;) Jan 25 18:06:32 Yeah. That's limiting. Jan 25 18:10:04 gah, there he goes again Jan 25 18:10:20 * ogra just , mailed him the list Jan 25 18:10:49 That's both of him gone. He may be reattaching. Jan 25 18:11:02 persia, i think we'll go with what we have on imx51 and not make the move to uboot Jan 25 18:11:24 ogra: Given the limitations of the bootloader and hardware, I think that's the right choice. Jan 25 18:11:27 i'm not really eager to have a three partition live image Jan 25 18:11:38 I don't think it's how it ought be done, but that's an entirely different matter. Jan 25 18:11:50 persia, its the only choice we have Jan 25 18:11:59 No. A three partition image would be very unfortunate. Jan 25 18:12:16 Yes, it seems that way. I'm not happy about it, but like I said, it comes down to hardware and firmware. Jan 25 18:12:42 non-fs (for uboot), /boot (so we can reformat that later and put the installed initramfs and kernel in place, livefs partition (which needs to stay mounted during install) Jan 25 18:12:54 Right. That would be bad. Jan 25 18:13:07 +thats the only possible design atm Jan 25 18:13:11 Right. Jan 25 18:13:25 only way around that would be if we got USB support into uboot Jan 25 18:13:32 then it could work like the dove Jan 25 18:13:36 But that's because of the specific board, and the current features available in the current bootloaders. Jan 25 18:13:42 Right. Jan 25 18:13:42 right Jan 25 18:13:50 asac, you got mail :) Jan 25 18:14:02 (but he has no tail) Jan 25 18:14:19 heh Jan 25 18:14:25 * ogra closes Bug 456659 Jan 25 18:14:26 Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,In progress] https://launchpad.net/bugs/456659 Jan 25 18:15:07 :D Jan 25 18:15:14 ogra: one point as of why its inferior to dove uboot might be good Jan 25 18:15:32 feel free to add points as you like Jan 25 18:16:48 asac, USB support is the actual only drawback, all other points are just results of working around the missing USB support (apart from the slower boot which is a uboot vs redboot design issue) Jan 25 18:19:20 plars, so for your prob i'd first check the installer logs, its very likely that the flash-kernel issue is just fallout of a former error Jan 25 18:19:38 ogra: will look through them Jan 25 18:20:16 ok Jan 25 18:20:17 thanks Jan 25 18:20:26 how did you get to a point where ubiquity actually does something ? Jan 25 18:20:48 i couls fill the forms with yesterdays image but it would never start the second step Jan 25 18:21:01 *could Jan 25 18:23:42 ok on the road again for a bit Jan 25 18:23:59 ogra: that was on imx51? Jan 25 18:24:05 yes Jan 25 18:24:13 seemed to be working alright today, didn't try it yesterday Jan 25 18:24:24 i had trashed my A2 install and wanted to reinstall from a fresh image Jan 25 18:24:46 well.. seemed to be working alright up to the end when it tried to flash-kernel Jan 25 18:24:47 in the end i rsynced back to A2 and used that Jan 25 18:25:26 or better i zsynced ... seems cdimage isnt offering rsync anymore Jan 25 18:25:32 ogra: ok, odd errors Jan 25 18:25:43 paste ? Jan 25 18:26:00 similar to this: Jan 25 18:26:02 Jan 25 16:21:53 ubuntu ubiquity: /usr/bin/dirname: line 909: c002bfac: command not found Jan 25 18:26:08 but several different binaries Jan 25 18:26:23 dpkg-divert, fis, etc Jan 25 18:26:28 all with similar errors Jan 25 18:26:45 aha Jan 25 18:27:27 sounds like either a filesystem or a coreutils (owner of dirname) issue Jan 25 18:27:56 ogra: but it's not just dirname returning that Jan 25 18:28:05 Jan 25 16:22:27 ubuntu in-target: /usr/bin/fis: 163: c05bf666: not found Jan 25 18:28:11 ok, then i'd say filesystem Jan 25 18:28:45 could also be thumb vy non thumb Jan 25 18:28:48 *vs Jan 25 18:28:59 fis was definately not rebuilt yet Jan 25 18:29:00 well I was trying to install to USB, but recent updates to that bug are seeming to indicate that there is no problem with it Jan 25 18:30:00 coreutils was rebuilt Jan 25 18:30:09 last upload dec. 12th Jan 25 18:30:19 so not thumb then Jan 25 18:31:06 what is confusing is that your first pasted line is not using in-target while your second one is Jan 25 18:31:47 ogra: I'm wondering if it's filesystem and related to bug 499881 Jan 25 18:31:48 Launchpad bug 499881 in linux-fsl-imx51 "usb storage with ext4 does not work in lucid" [High,Confirmed] https://launchpad.net/bugs/499881 Jan 25 18:31:50 if it would all be in-target stuff that would point to USB ... but the dirname error above is clearly from the livefs and not running on the target disk Jan 25 18:32:13 plars, not for dirname Jan 25 18:32:13 thats run from the livefs Jan 25 18:32:41 ogra: I have a similar error from dpkg-divert, also run from livefs Jan 25 18:32:50 in-target is the wrapper that calls commands on the target disk Jan 25 18:33:09 if the lines are not prefixed with in-target thats points to stuff running from the livefs Jan 25 18:33:38 so probably kernel Jan 25 18:34:13 since it happens on SD as well as on USB Jan 25 18:38:35 plars, for now, bug it and attach all installer logs dmesg and friends ... Jan 25 18:38:40 * ogra has to leave now Jan 25 18:38:49 ogra: seeing a lot of this: usb 1-1.1: reset high speed USB device using fsl-ehci and address 3 Jan 25 18:38:57 aha Jan 25 18:39:00 so I think it almost has to be related to that bug I pasted earlier Jan 25 18:39:14 is that your only USB device attached ? Jan 25 18:39:27 ogra: also have keyboard and mouse Jan 25 18:39:35 ogra: but otherwise, yes Jan 25 18:39:39 i.e. i have a USB WIFI card that has a fat partition for the driver that shows exactly the same issue Jan 25 18:39:55 silly hybrid HW for windows Jan 25 18:39:58 ogra: mouse/kbd go through a hub, usb stick is directly attached to the board Jan 25 18:40:18 right, high speed also indicates its the disk Jan 25 18:40:29 yes Jan 25 18:40:58 though note that redboot is pretty outdated ... it might not initalize all HW omn the b3 properly, could be its fault Jan 25 18:41:14 i'll upload a new reboot tomorrow since we're unlikly to go for uboot Jan 25 18:41:34 (we're also still using the karmic binary) Jan 25 18:41:44 anyway, off ... Jan 25 18:41:53 else my GF kills me Jan 25 18:41:54 :) **** ENDING LOGGING AT Tue Jan 26 02:59:56 2010