Rx Invalid Frag numbers from /sbin/iwconfig msh0
Does anyone here know precisely what the numbers related to Rx invalid frag (/sbin/iwconfig msh0) actually mean on the XO? I'm seeing very large numbers--with large deltas. Sometimes as much as 2 of these per second. Cheers Marcus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
School server on F8?
Are there any F8 RPMs for the school-server code? Our behemoth server is F8-based, partially because some of the hardware is only supported in F8 Kernels 2.6.24 and greater (Marvell P-ATA chips, etc). -- Marcus LeechMail: Dept 1A12, M/S: 04352P16 Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 Strategic Standards Nortel Networks [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Connector spec for XO power connector
Is there a pointer to (for example) a Digi-key part number for the DC power connector for the XO? I think I want to clean up the power situation in the lab, and run a bunch of XOs off of one or more clean DC supplies ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Cannot see activities in joyride-2005
Michael Stone wrote: Dov, First, please file a ticket that sugar fails to start up if /home/olpc is empty/missing. Please CC at least mstone and marco on it. Next, put your /home back in place and try to start Sugar. If you're successful, then go to the list view and click some of the stars so that they become filled with color. Then return to the ring view. Your activities should be present. File bugs if they aren't. Finally, which activities were you expecting to see in the ring view when you updated to joyride-2005? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel On a related note, I upgraded from Ship.2 656 to joyride-2002 yesterday on some of my lab machines, and ain't no activities at all. I ran into this a few weeks ago with my own personal XO, and I can't remember the solution (which, I think, involved downloading and installing an RPM). -- Marcus LeechMail: Dept 1A12, M/S: 04352P16 Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 Strategic Standards Nortel Networks [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Activities bundle
I can't remember where the .rpm is for all the activities for late-model (recent joyride), since the joyride images no longer seem to contain any activities. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Bricking for fun and pleasure
I bricked a lab machine today by doing an olpc-update joyride-2000 on it--it was previously running ship.2 Build 656. The system was unbootable, so I asked it to do a fallback boot, which fell back to the 656 load, but now the /bin/su command was made non-executable to ordinary plebs. This effectively prevents me from doing the things I want to do. Yikes! Now I *really* need developer keys for the XOs in my lab, so that I can cleanly back out of a situation like this. Sigh. Marcus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bricking for fun and pleasure
C. Scott Ananian wrote: On Mon, Jun 2, 2008 at 1:51 PM, Marcus Leech [EMAIL PROTECTED] wrote: I bricked a lab machine today by doing an olpc-update joyride-2000 on it--it was previously running ship.2 Build 656. First off, a matter of nomenclature - not really directed at you, Marcus, but for devel@ in general. Please don't use the term brick unless the machine is *actually* rendered completely inoperable w/o hardware intervention. What you are reporting is just a software problem, and you can recover it simply using the secure reflash procedure documented on the wiki: http://wiki.laptop.org/go/Secure_reflash Yes, I realized right after I sent the original message that brick carries both more emotional, and more technical content than I had perhaps intended. Mea Culpa. The system was unbootable, so I asked it to do a fallback boot, which fell back to the 656 load, but now the /bin/su command was made non-executable to ordinary plebs. This effectively prevents me from doing the things I want to do. Yikes! This sounds like a valid issue with the rsync upgrade procedure, which I've filed as http://dev.laptop.org/ticket/7158 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
What's the latest safe Joyride build to use?
I updgraded from 1918 to 1946 today, and found that most of the activities had disappeared, they weren't even in the list view. -- Marcus LeechMail: Dept 1A12, M/S: 04352P16 Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 Strategic Standards Nortel Networks [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
School server stuff
A few questions: What driver is required on an ordinary Linux system for the active antennae? [I ask because plugging one in to a hot-off-the-presses F9 system causes said system to freeze instantly :-( ] The XS images--are they designed for XO hardware, or garden variety desktop hardware? If the XS image is just for the XO (to turn it into an XS), how do I turn a garden-variety Linux/Fedora system into an XS? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: 65-node simple mesh test (and counting... ;-)
Robert, this is great. Do you think there is any chance that we will be able to remotely use this testbed also? regards, Pol The plan is to make the lab machines reachable from the Internet. Our IS organization has agreed to do this, and has earmarked a raft of somewhat-older ethernet switches for us, and they have agreed to help out with wiring, and they can get us Internet access into the lab no problem (we have so many labs/demos/special-events that require Internet access, that IS has a well-established process for doing this). A potentially semi-blocker is that we don't have resources to acquire all the USB Ethernet dongles that we'll need to make this work. But I think Kim mentioned that there's a pool of them somewhere that we can have. Cheers Marcus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: 65-node simple mesh test (and counting... ;-)
The following graph is the cumulative distribution function. It shows that, on average, each XO has received about 95% of the profiles of the rest of the nodes within just 20 seconds. This performance boost is due to the fact that each XO queried for its profile, responds by broadcasting the profile, instead of unicasting it to the requester. As a result, the other nodes receive the profile too and the next node is queried, yielding a linear cost, instead of a quadratic one. http://wiki.laptop.org/images/7/72/65-cdf-1.png I'd be *very* interested to compare the distribution on a wired network. It seems to me that given the broadcast model, everybody should see everybody else in much shorter time than the 55 seconds shown in the outlying cluster on that graph. For example, if you plugged all of those 65 Xos into a wired network (100Mbits/sec), then if the convergence time shrinks by roughly a factor of two (100Mbits vs 54Mbits), then we know that the wireless networking stuff on the XO is basically functioning correctly. If, however, the convergence time becomes *very* much shorter on a wired network (let's say by a factor of 5 or more), then something is likely wrong with the 802.11 goop on the XO. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: 65-node simple mesh test (and counting... ;-)
Marcus, this is indeed an interesting idea. However it has a significant problem: wiring up more than 60 XOs onto a switch requires equipment, time and space that OLPC cannot presently provide. Such a testbed though is absolutely necessary not only as a proof of concept for your suggestion, but also for doing large scale mesh network testing in general. Indeed, it does require more infrastructure than 60 Xos in simple mesh. My hope is that the XO lab we're building here will have enough infrastructure in it to make such scenarios viable. The common, but erroneous, assumption is often made that a wireless network is just like a wired network, but with the wires removed. So very true! On a wireless network, broadcasts are successfully received with much lower probability. RF is mysterious and magical, and all sorts of connection asymmetries, near-field effects, and radiation lobe patterns conspire to make it unlikely that *everyone* can hear you equally at once -- and then you get into remote collisions and other mechanisms that make you unaware that not everyone heard you. And there is not 'ack' mechanism for 802.11 broadcast. All these are true also, but I think we're mystifying things a little bit here. The wireless medium is unpredictable mainly because its properties are also a function of time (a non-issue in wired networks), but at least (thank God!) it [the wireless medium] does not discriminate between broadcast and unicast frames! Adding an ack scheme to broadcasts should yield equal (or even better due to lowered speed) reliability using broadcast frames. Even without the ack scheme, I noticed that, on average, some 95% of the data transmitted over broadcast are successfully received on all nodes. We are throwing this away by discarding it on our wireless interfaces. Pol I was playing in packet-radio circles long before 802.11 was even a gleam in anyones eye :-) We had to deal with hidden-terminal issues, non-uniform propagation, etc. The purpose of the experiment I proposed above (measuring the ratio between a Cerebro network equilibrating over both a wired and a wireless network). Yes, there will be differences, but if they're *large* compared to the raw bandwidth ratios, then something isn't working right, particularly if all the Xos are in the same room. You shouldn't have hidden-terminal issues. Yes, there will be laptops that are in the null of another laptops radiation pattern, but in terms of absolute received power, even being in a null (unless it's a *very* deep null indeed) shouldn't dehance the SNR so as to not be able to coherently receive bits. The other thing that I wonder about is the collision behaviour in real life of an 802.11 network. I understand that the network uses a Collision Avoidance (CA) scheme, but I wonder how effective it is in real life. Back in my packet-radio days, we moved from a pure CSMA scheme to one that used P-persistant CSMA, with static determination of P values. This vastly improved overall throughput, and made collisions more rare (not zero, but a lot better). How does the collision model/scheme change between AP mode and ad-hoc/mesh modes? Cheers Marcus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Collaboration tools running over standard ethernet
If your (virtual) XO doesn't have an 802.11 interface, do the collaboration tools still work, and if so, how? -- Marcus LeechMail: Dept 1A12, M/S: 04352P16 Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 Strategic Standards Nortel Networks [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: New faster build 1889
Also, was the fact that it bricks your machine design intent? I'm sad now. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Stone Sent: Monday, April 21, 2008 2:57 PM To: Build Announcer v2 Cc: [EMAIL PROTECTED] Subject: Re: New faster build 1889 On Mon, Apr 21, 2008 at 12:30:32PM -0400, Build Announcer v2 wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build1889 Changes in build 1889 from build: 1870 Size delta: 17.43M +kernel-PAE 2.6.23.1-21.fc7 -python-jinja 1.2-2.fc7 +python-jinja 1.2-1.fc7 -kernel 2.6.22-20080408.1.olpc.de2a86ff3b60edc Did someone intentionally downgrade python-jinja? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Where did all the activities go?
I just updated from a 1700-series Joyride to Joyride 1855. There's no activity bar along the bottom of the home page. Help? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
XENified images for XO
Has anyone done any work on building XENified images for XO? I'm interested in this for building a large-scale virtualized XO environment for testing purposes. The other option is to run the XO image in HVM mode, but that limits which processors I can use to host such a thing. Cheers -- Marcus LeechMail: Dept 1A12, M/S: 04352P16 Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 Strategic Standards Nortel Networks [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1606
Build Announcer v2 wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1606 Changes in build 1606 from build: 1605 Size delta: 0M -kernel 2.6.22-20080118.2.olpc.a985ba6d19d39cc +kernel 2.6.22-20080129.1.olpc.8842a09250ff229 So, with this build, the battery light keeps blinking RED every few seconds, even when I'm plugged-in. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC library] MATLAB for OLPC?
C. Scott Ananian wrote: On Jan 28, 2008 5:24 PM, Ivan Krstić [EMAIL PROTECTED] wrote: On Jan 28, 2008, at 8:04 PM, Cleve Moler wrote: (I doubt that MATLAB runs in the OLPC, but I'm not sure.) There are a number of open-source replacements for MATLAB, including GNU Octave ( http://www.gnu.org/software/octave/ ) and Maxima ( http://maxima.sourceforge.net/ ). --scott I was just about to say the same thing. There's also R (The open-source replacement for 'S'). When my daughter was taking introductory algebra, I showed here the algebraic solver in xMaxima. She said that's cheating :-) ex ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Joyride---Update.1 transition
Something I'm curious about (for a set of slides I'm working on) is how stuff transitions from Joyride to Update.1 builds--both the mechanics (how the bits get copied), and the procedural and decision processes involved. Cheers Marcus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1514
Build Announcer Script wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1514/ +kernel.i586 0:2.6.22-20071213.7.olpc.807beb7d0b8a49a -kernel.i586 0:2.6.22-20071231.3.olpc.71454c965b73c4e -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel Well, WPA_PSK no longer works with this build. How do I revert? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO as a scientific platform: wiki page
David W Hogg wrote: FWIW, I started a wiki page (on my research group wiki) about setting up my G1G1 XO for scientific writing on the road (and, eventually, research, but right now my job is to write a grant proposal on the XO as I travel around this weekend). http://howdy.physics.nyu.edu/index.php/Setting_up_an_XO Sorry for the spam. Hogg That's cool. I dabble, perhaps more-than-a-little, in radio astronomy, and maintain the radio-astronomy subtree for Gnu Radio. The XO isn't quite up to the task of the kind of signal processing I do, but as a back-end to something like the Itty Bitty Telescope being promoted by the Society of Amateur Radio Astronomers, the XO would make a dandy little field data collector. Cheers Marcus signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1452
Bernardo Innocenti wrote: :-) I also disapprove adding bulky packages to our builds just for sake of debugging. In this case, this is said to be only temporary until we have shaken the most serious networking problems. There is still plenty of opportunity for debloating our images, and I'm willing to pursue it, but it is not clear if this is a valued goal. While I'm sympathetic to removing bulk, I'm someone who developed his first networking stack at the age of 16 or 17 around 1980. I think we shouldn't rush too hastily in making assumptions about what 12-year-old budding software genii will actually need. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
WPA anomalies in recent Joyride builds
I use WPA-PSK (WPA personal) at home, and I've noticed anomalies. One of the big ones is that it keeps re-prompting for the passphrase (this is with Joyride 1438), and tearing-down the association. I looked at /var/log/messages while this was going on, and it seems like it starts the association logic, puts up the password prompt, and then times out the association attempt after 8 seconds--which typically isn't enough time to type in the passphrase! It turns out that NetworkManager has a wired-in 8 second timer for re-association attempts, and 20 seconds for initial association attempts. I'm not sure how this seems to work OK on a regular Fedora system--which is using almost the same version of NetworkManager. It's possible that the password-prompting happens before we go into the timer-controlled region of the state machine--have we mucked with this at all? Is the password dialog one of our own, or just a standard one with Sugar decorations? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: WPA not working after upgrade to Joyride 1430.
Guillaume Desmottes wrote: Le dimanche 16 décembre 2007 à 23:03 -0500, Marcus Leech a écrit : I was running Joyride 1407, but upgraded to 1430. WPA appears to no longer function. I know that WPA broke around 1416, but I guess I assumed that it would have been fixed. But perhaps not? That's a known bug. See http://dev.laptop.org/ticket/5485 G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel OK. It says that it's now fixed. Can I expect the latest joyride build to include this fix? Also, can I simply dd the JFFS2 image file onto a USB stick, and do the upgrade from USB thing? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Joyride 1436 a bust
Multitudinous modprobe errors on start. Avahi doesn't start HAL hangs for a LONG time various pieces of filesystem appear to not be there, including bits required by Network Manager various bits of dbus filesystem not there, so dbus doesn't start ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Recent Joyride builds busted bad
Missing /usr/lib/modules/kernel/*.dep, etc. This is fixed by doing a
depmod -a after upgrading.
But there's also chunks of filesystem missing:
/var/lock/subsys/{a-bunch-of-things}
/var/run/dbus
/security
/var/lib/stateless/{a-bunch-of-things}
I looked at the build.logs for 1438, 1437, and 1436, and there's nothing
that really leaps out at me as a cause for this.
The upshot of this is that HAL hangs for a long time (perhaps waiting
for a dbus that will never appear, because DBUS
failed to start due to /var/run/dbus not being there).
X fails to start as well, with init doing its darndest to get it
started, in an annoying infinite loop.
A couple of RC scripts failed to find the find command, which perhaps
explains missing chunks of filesystem
(particularly under /var???).
It's a frooking mess, I'd say :-)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Recent Joyride builds busted bad
Bernardo Innocenti wrote: I'm surprised how much stuff was installed only as a consequence of mkinitrd. The Fedora people should be informed of this problem, as it is likely to bite on every embedded distro based off Fedora. So, things like find and cpio were only listed as dependencies of mkinitrd, and not in any other packages? That's really weird! A lot of these things (find, grep, tar, cpio, gzip, a-plethora-of-others) should likely be always installed, since the disk space penalty is low, and they are such *basic* utilities that they should always (IMNSHO) get installed. A problem with the traditional dependency model for things like utility commands is that it's hard to describe the dependency graph of the uber application, which is the end-user (or in this case, developer) themselves :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Shutting down fds prior to execvpe in rainbow/inject.py: joyride 247 under Qemu
Albert Cahalan wrote: Marcus Leech writes: I experimentally put some code just before the execvpe() in inject.py to close FDs = 3 and = 10. I picked 10 out of the air, but I wouldn't expect there to be many open file descriptors at that point. Actually, given the semantics of dup(), you could use it to probe what the maximum FD number is just before execvpe(), so the terminating condition could be something like = dup(0). I don't see how dup() would help you. Remember, you could get back fd 123 even if fd 12345 was the last one allocated and is still in use. You get the lowest free fd. You can do readdir() on /proc/self/fd to list them, being careful to not close the fd used for reading the directory until you have read the whole directory. Yes, you're quite right. Late-night fuzzy thinking on my part. signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
