| === lopi is now known as Lopi | ||
| xranby | diwic: the contextgetstate.patch worked fine.. and solved the exception bug on arm | 08:45 |
|---|---|---|
| diwic | xranby, \o/ | 08:45 |
| diwic | xranby, was it enough to bring up the hajpa hajpa? | 08:46 |
| xranby | yeah at least for one of the two jvm's | 08:46 |
| xranby | the other jvm had its own classloader bug.. | 08:46 |
| diwic | xranby, but that was maybe unrelated to pulseaudio? | 08:47 |
| xranby | diwic: correct the pulse-audio java layer looks bugfixed now , thanks! the only thing that can break it now are if the java virtual machine have missed to implement some part of the jvm specification | 08:48 |
| diwic | ok | 08:48 |
| xranby | diwic: and for arm we are in the situation that oracle do not provide an opensource reference implementation like on x86 :/ so it takes time to get everything super polished | 08:49 |
| diwic | xranby, ok so a lot of that reference implementation is written in platform dependent language (e g assembly?) | 08:51 |
| diwic | xranby, vaguely remember you tried to explain some of that stuff at latest UDS | 08:51 |
| xranby | diwic: yes highly platform dependent, and optimized java virtual machine port contains about 80000 lines of platformspecific code | 08:52 |
| diwic | ouch | 08:53 |
| TheSeven | hm, is the ARM cross compiler toolchain for x86 currently broken? | 11:09 |
| TheSeven | (in oneiric) | 11:09 |
| TheSeven | apparently the libgcc1-armel-cross package is missing | 11:12 |
| === Quintasan_ is now known as Quintasan | ||
| xranby | diwic: it turned out that the reverence implementation did not strictly implement the jni spec :) http://icedtea.classpath.org/hg/icedtea6/rev/23b9bb41de6d | 14:31 |
| xranby | now \o/ hajpa hajpa work on arm | 14:31 |
| diwic | hajpa hajpa! | 14:32 |
| janimo | infinity, ac100-tarball-installer in moderation queue | 14:35 |
| GrueMaster | ppisati: Can you look at Bug 865479? Thanks. | 16:04 |
| ubot2 | Launchpad bug 865479 in linux-ti-omap4 "wl1271: ERROR ELP wakeup timeout" [Undecided,New] https://launchpad.net/bugs/865479 | 16:04 |
| GrueMaster | Not sure that it is critical, just that it exists. | 16:04 |
| GrueMaster | infinity: I'm still consistently getting oem-config to respawn. Looking at the log files, I believe this may be the problem: Oct 3 08:12:05 localhost ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable | 16:07 |
| GrueMaster | Hard to tell, as that message is almost a minute before the respawn message, but it is the only negative message before the next instance of oem-config respawn in syslog. | 16:09 |
| brandini | I tried to get mongodb working over teh weekend but didn't make it very far | 16:12 |
| infinity | GrueMaster: I can't get this respawn thing happening at all. :/ | 16:39 |
| infinity | GrueMaster: I can get the installer to explode in general based on cron.daily eating the system alive. That's about it. | 16:40 |
| infinity | (And I plan to hack around that with a kludge today) | 16:40 |
| GrueMaster | Pfft. Figures. Most of the bugs I find are easily reproducible here, but no where else. | 16:41 |
| GrueMaster | I wonder if the cron.daily stuff is blocking me. Maybe it is doing an apt-get update at the same time? | 16:44 |
| GrueMaster | That could explain why I see it and others don't. Timing. | 16:45 |
| GrueMaster | Oh, and the slideshow works again. :) | 16:46 |
| brandini | what steps are involved in bringing support for a new chip like the Cortex A9 to an OS | 17:03 |
| infinity | The A9 is new? | 17:05 |
| infinity | GrueMaster: The cron.daily thing can just explode in general due to system load. I think the debconf DB thing might be a red herring, though. Let me check the log on a successful install run. | 17:05 |
| infinity | GrueMaster: Yeah, I have that same debconf locking spew on a successful install. | 17:07 |
| infinity | GrueMaster: So, while it's likely a bug somewhere, it's probably not causing an issue either. | 17:07 |
| brandini | infinity: new to that os :) | 17:08 |
| GrueMaster | I just had ubiquity fall apart when I tried to run without any networking. Really bad. | 17:08 |
| infinity | brandini: Well, things like A8->A9 are really just about building support into toolchains and kernels for shiny new features you might care about, and building support into bootloaders to bring them up. | 17:09 |
| GrueMaster | Hmm. Something caused the filesystem to remount read-only. | 17:09 |
| infinity | brandini: But since all your binaries already run (yay backward compat), it's not much effort. | 17:09 |
| brandini | ok | 17:10 |
| infinity | GrueMaster: Read-only filesystems usually point to hardware hating you, with a 5% chance of kernel bug... | 17:10 |
| infinity | (Well, less than 5%, since we tightly control our target platforms here, and we aren't all seeing ro filesystems) | 17:10 |
| GrueMaster | infinity: I'm the guy that nails that 5%. | 17:11 |
| infinity | Or your hardware hates you. ;) | 17:11 |
| infinity | I hate to beat the same dead horse, but when working on SD, I'd tend to blame cards for a filesystem going tits-up before anything else. | 17:12 |
| infinity | And I really think we should do most of our test installs on hard drives. | 17:12 |
| GrueMaster | Multiple SD cards and multiple Panda's? I highly doubt I can be having a complete failure here. The odds are against it being my HW. | 17:12 |
| infinity | Except hitting a card once in a while to make sure the code paths still do what we think they do. :P | 17:12 |
| infinity | GrueMaster: The odds for hardware are still higher than the idea that a deterministic automated installer only fails in one person's house. | 17:13 |
| GrueMaster | infinity: Can't test on hard drives. The preinstalled images are designed around SD. It would be equivalent to testing in a VM. | 17:13 |
| infinity | GrueMaster: And you've been beating on the same SD cards for a while, I'd guess. | 17:13 |
| GrueMaster | Some are almost brand new since A2. | 17:13 |
| infinity | GrueMaster: Preinstalled would work on an HDD just fine. | 17:14 |
| infinity | (Just need to write it differently) | 17:14 |
| infinity | But yeah. I know the situation we're stuck in. I just dislike it. :P | 17:14 |
| infinity | I have 5 cards in front of me, and I only trust one of them. | 17:14 |
| infinity | And that trust won't last forever. | 17:14 |
| GrueMaster | I have ~2 different cards per board at my disposal. Varying sizes, speeds, an brands. To see these issues across multiple SD cards on Panda A1, A2, and A3 systems is extremely rare. | 17:16 |
| infinity | Well, wait, which issues? The ro filesystem above sounded like a one-off. | 17:16 |
| GrueMaster | Remember, I have almost 10 years in hardware validation. I know very well how to triage hardware failures. | 17:17 |
| GrueMaster | That was the first time I saw it, but also the first time I booted w/o networking. | 17:17 |
| infinity | Correlation and causation not being the same thing. :P | 17:17 |
| GrueMaster | And ubiquity crashed with a UBI failure of some sort. Just getting ready to look at the log. | 17:18 |
| infinity | But it's possible 'fixrtc' stopped working or some such, which could lead to network->badtime->fsbreak. | 17:18 |
| infinity | But that should break early. | 17:18 |
| infinity | The log will be useless if the filesystem is ro. Unless you're really lucky. | 17:18 |
| infinity | dmesg is more likely to be useful. | 17:19 |
| GrueMaster | fixrtc only runs during boot in initrd I thought. | 17:19 |
| infinity | Well, it's an at-boot thing. To fix the clock... | 17:19 |
| infinity | We don't then break the clock later. :P | 17:19 |
| GrueMaster | Since these images don't have any way to get a terminal session without first modifying the image prior to boot, there is no way to debug a live session. | 17:19 |
| infinity | So, if it's not working, then without ntpdate, your clock will be a sad panda. | 17:19 |
| infinity | Yeah, that's so obviously an ARM preinstalled bug. I noticed it with the last week of debugging. :/ | 17:20 |
| infinity | Since a real live system has the "ubnutu" user, and a real oem-config system has an oem user. | 17:21 |
| infinity | But we fail to have either. | 17:21 |
| infinity | Not fixing that before release, though. | 17:21 |
| infinity | Worth having on the TODO if jasper survives. | 17:21 |
| GrueMaster | Log files are a bust. complete corruption prior to any ubiquity info. Interesting to see network manager completely freak out though. | 17:23 |
| GrueMaster | and I have asked for debug hooks of some sort since we started doing preinstalled images. | 17:24 |
| infinity | GrueMaster: When does the loop happen? | 17:55 |
| infinity | GrueMaster: I'm going to sit here and try to reproduce this... | 17:55 |
| GrueMaster | Right around the time it says that it is copying log files. | 17:56 |
| infinity | GrueMaster: Does everything complete (including the removal)? | 17:56 |
| GrueMaster | Does not start the removal. | 17:56 |
| infinity | Hrm. | 17:57 |
| infinity | I also might not be able to fix the anacron issue this cycle, the more I think about it. | 17:57 |
| infinity | The fix needs to be in ubiquity, and might be regression-inducing. | 17:57 |
| infinity | I realised I can't hack around it in jasper, because we don't actually have a sane clock yet. | 17:58 |
| GrueMaster | Nothing (other than what I previously stated about the config.dat) indicates an issue in any log files I have. | 17:58 |
| GrueMaster | Hmm. Doesn't appear to like me hacking in an additional debug user prior to oem-config running. It has been sitting on "Creating User" for a while now. | 18:00 |
| GrueMaster | Grrr, Doesn't appear to like my shadow entry. | 18:14 |
| infinity | GrueMaster: *poke* | 21:06 |
| infinity | GrueMaster: Can you do some test runs on your problematic systems with 's/update-apt-xapian-index -q/update-apt-xapian-index -q -u/' in /etc/cron.daily/apt ? | 21:07 |
| infinity | GrueMaster: Seems to have made mine slightly less grumpy. | 21:07 |
| === NCommander is now known as Guest45434 | ||
| GrueMaster | infinity: On it now. | 21:30 |
| GrueMaster | (took an extended lunch break). | 21:30 |
| infinity | GrueMaster: All good. Food sounds like a stellar plan to me too. | 21:30 |
| GrueMaster | Starting the test now on a freshly zero'd & flashed drive. Even if this solves the oem-config respawn, we still have another issue where ubiquity crashes when no network available. | 21:49 |
| === lopi is now known as Lopi | ||
| infinity | GrueMaster: Do you have logs for the no-network thing? That one couldn't have been silent... I hope. | 21:54 |
| infinity | GrueMaster: Or even an apport-filed bug would be nice. | 21:54 |
| GrueMaster | Well, that was part of the problem. ubiquity crashed saying it would spawn a desktop session for debugging, but that failed to materialize. And nothing was captured in the logs as the system had gone read-only. | 21:55 |
| GrueMaster | I'll try to reproduce it as well. I would really like to have an image that I can get to a login for testing though. Otherwise I am just spinning my wheels on useless stuff. | 21:56 |
| infinity | Oh, that was the read-only one, right. | 21:56 |
| infinity | I suspect that one might not be reproducible, but if it is, great. | 21:56 |
| infinity | If the FS isn't readonly, ubiquity crashes will spawn apport, which is good enough for filing bugs with logs, at any rate. | 21:57 |
| infinity | If jasper survives another cycle, we should remember to add the oem user, though. | 21:57 |
| GrueMaster | I'll prep another SD to test that, but for desktop, I am kind of limited to single tasking (1 monitor & keyboard for Pandas). | 21:58 |
| infinity | Oh, wait. No. There shouldn't be one, it's deleted by oem-config-prepare before rebooting. | 21:58 |
| infinity | So, oem-config in general just has no way to debug it. Hrm. | 21:58 |
| GrueMaster | Not that I have found useful. | 21:59 |
| infinity | I've been testing on my ac100 too. Which picks up slightly different bugs just due to the timing of having faster storage. | 21:59 |
| infinity | Panda and ac100 together seem to get most everything.. Except your respawn issue. :/ | 21:59 |
| GrueMaster | And fail. The cron.daily fix is bust. | 21:59 |
| infinity | Well, it does address *a* problem. Just not yours, apparently. | 22:00 |
| infinity | And I honestly can't get ubiquity to crash/respawn at all (or finish/respawn, or any combination thereof), so I'm kinda stumped. | 22:00 |
| infinity | A full set of logs (heck, just /var/log tarred up) from the SD might be enlightening. | 22:01 |
| GrueMaster | Unfortunately, it isn't as enlightening as one would expect. I have yet to find a significant entry in any logs under /var/log. | 22:02 |
| GrueMaster | The best I had was the debconf config.dat file (which you said wasn't significant). | 22:03 |
| GrueMaster | Sigh. I hate the automount "feature". It really annoys me. And what's with the AC100 showing (and mounting) all of the SERVICEV001 partitions? | 22:07 |
| infinity | GrueMaster: It doesn't? | 22:09 |
| infinity | GrueMaster: At least, it doesn't here. | 22:09 |
| infinity | GrueMaster: You sure that's not a freshly-flashed card? | 22:10 |
| GrueMaster | Could be because I upgraded from Natty. | 22:10 |
| infinity | (It's only SERVICEV001 after it's booted) | 22:10 |
| GrueMaster | I'm talking about the eMMC. | 22:10 |
| infinity | Oh. yeah, I get no weirdness here. | 22:11 |
| infinity | You might want to try the recent images. :) | 22:11 |
| infinity | They actually work better than OMAP. | 22:11 |
| infinity | Which is a bit sad. | 22:11 |
| infinity | But yay for faster storage. | 22:11 |
| GrueMaster | As I said, if there is >.01% chance of weirdness, I will hit it. | 22:11 |
| infinity | Anyhow. Going to take a late lunch. | 22:12 |
| infinity | Back later to keep banging on things. | 22:12 |
| infinity | On the looping installer thing, if you can just let it settle a bit after it loops, so it's sure to have flushed some buffers, yank the card, and give me /var/log in a tarball, maybe I'll spot something that doesn't add up compared to one here. | 22:13 |
| GrueMaster | I usually wait until it comes up, then switch to text console and 3-finger reset so everything shuts down cleanly. | 22:14 |
| infinity | You could just alt-sysrq-s to force a sync, wait for the SD light to go out, and yank it. That has the advantage of basically being a snapshot of the problem area without reboot fluff afterward. | 22:16 |
| GrueMaster | reboot fluff is minimal (and tarball is in my people.c.c dir (firtname)/20111003-oem-fail-logs.tgz | 22:17 |
| infinity | Great, I'll look at it after lunch. | 22:18 |
| infinity | That's the re-spawn one? | 22:18 |
| GrueMaster | starting on the network-less run. | 22:18 |
| GrueMaster | Yes. | 22:18 |
| infinity | Kay. | 22:18 |
| GrueMaster | W/o network crashes much more ugly before it even gets that far.\ | 22:19 |
| GrueMaster | Grr. Network crash didn't happen this time around, but oem-config respan did. | 22:27 |
| === Guest45434 is now known as NCommander | ||
| === NCommander is now known as Guest61019 | ||
| === NCommand1r is now known as NCommander | ||
| === Guest16725 is now known as StevenK | ||
| === Jack87|Away is now known as Jack87 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!