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