The test efforts were divided in 2 tracks: - generating a lot of network traffic in an attempt to repro the netwokr-related lockups - run through parts of the smoketest revisiting bugs found last week
We didn't have time to explore other areas of the smoketest as we found plenty to keep us busy. Network lockups - none ---------------------- For the network traffic test, I associated 2 XOs to a XS with an AA and generated wifi traffic with while true; do wget http://localkernelmirror/path/to/kernel.tar.gz ; rm kernel* ; done; wget reported between ~400KB/s on both (probably bottlenecked on a slow switch - the nz kernel mirror is a dozen meters away). We did not see any glitch at all. The night before, 6 XOs had updated from 2270 to 2301 using olpc-update with not issues. And when we started the tests I quickly ran the activities update on all 6 XOs. In short, we failed to see any anomaly -- the RF env is very lightly loaded in this place. A few faint beacons can be seen, and there are 2 other strong signals - neither in the same channel. Smoketests and revisiting bugs ------------------------------ In general the system worked well, though we didn't get through the whole smoketest. I am focussing here on the notably bad issues :-) - which I tagged 'blocker?:8.2.0'. We tried to explore these deeper, get logs and narrow down on steps-to-repro. Feel free to ask for more info and retests on each bug. - Measure is still broken #7771 - this one looks like a trivial dependency is missing. Add the python-numeric rpm to the build... - Record is still broken #7887 - but more consistenly than before. Logs attached showing the last acrions before the segfaults. If you can tell me where the coredump gets stored, I'll attach one too... We got a lot of almost consistent *hard* lockups related to sound. TamTamJam doesn't start, and Acoustic Measure (Distance) locks us badly when using the sound. This is a lot more consistent than in joyride-2270 (where we had seen 1 machine lock up consistently on TamTamMini, and nothing else), although still never 100%. Acoustic Measure is the most consistent reproducer of the problem. See #7996 #7989 Trying to revisit #7985 (Journal does not always show mounted USB drives) and using USB drives to pass around activity logs we came across a new and very nasty bug: when you unmount a USB drive from the Journal, it doesn't really unmount it. We nuked a couple of FAT-formatted USB drives (losing all data) to this bug, because FAT is particularly unhappy about unclean unmounts. Filed as #7993, I'd characterise this as a high-priority dataloss blocker. This build eats USB drives with gusto. (Luckily, we didn't lose any data. Thanks for asking :-) ) Credits to Alastair Munro and Tabitha Roder for the bug hunting. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel