radio off guarantee?

[James Cameron]

I'm taking a few units to demo at a radiotelescope open day in Parkes,
NSW, Australia, this weekend.

I've been asked to ensure the radios are off, since the telescope will
be observing at the time, in the spectrum the laptops emit in.

Is this sequence sufficient:

- rename usb8xxx.ko to usb8xxx.disabled,
- power down,
- remove battery and AC adaptor,
- power up.

On the B4, this prevents the two left-hand LEDs from lighting ... the
keyhole LED and the Star Wars TIE fighter LED. But on build 566 at
least the X server does not start. "Xlib: connection to ":0.0" refused
by server".

Workaround is to put usb8xxx.ko back into place, modprobe it, and use
Control/Alt/Backspace on the X server console. But then the wireless is
on. ;-}

--
James Cameron mailto:***@us.netrek.org http://quozl.netrek.org/

[Bernardo Innocenti]

Subject: Re: radio off guarantee?

To: James Cameron <***@laptop.org>,***@lists.laptop.org

Cc:

Bcc:

-=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=-

James Cameron wrote:



> - rename usb8xxx.ko to usb8xxx.disabled,

> - power down,

> - remove battery and AC adaptor,

> - power up.

>

> On the B4, this prevents the two left-hand LEDs from lighting ... the

> keyhole LED and the Star Wars TIE fighter LED. But on build 566 at

> least the X server does not start. "Xlib: connection to ":0.0" refused

> by server".



I don't see how removing the usb8xxx kernel driver may affect X client

connections. I'd say the two have to be independent.



Also, I'm a bit confused: the error message you see does not mean that X

server is not starting. On the countrary, you only get it when the

server is running and you try to start a client without proper

authorization.



Where do you see this message? Check for $XAUTHORITY: it should point

to a file containing the xauth cookie.



--

// Bernardo Innocenti - http://www.codewiz.org/

\X/ One Laptop Per Child - http://www.laptop.org/

[James Cameron]

Low priority ... removing the usb8xxx kernel driver is not a
conventional use case.

On Mon, Sep 17, 2007 at 10:32:35PM -0400, Bernardo Innocenti wrote:
> I don't see how removing the usb8xxx kernel driver may affect X client
> connections. I'd say the two have to be independent.

I agree. But it happens. I've reproduced it. I'll try some later
builds though. 566 is a bit old now. Sorry.

> Where do you see this message?

By pressing Control/Alt/F2. The X server /usr/bin/X has file descriptor
2 (stderr) anchored to /dev/tty2, per "ls -l /proc/`pgrep X`/fd" ...
therefore the second text console contains the message, repeating.

> Check for $XAUTHORITY: it should point to a file containing the xauth
> cookie.

Got it. /proc/`pgrep X`/environ contains XAUTHORITY which points to
/home/olpc/.Xauthority last changed several days ago, which contains a
hostname of xo-05-27-F1.localdomain, but the current /bin/hostname
output is "localhost.localdomain" ... so I conjecture that removing the
wireless kernel driver results in the hostname not being the same as
what it was before.

--
James Cameron mailto:***@us.netrek.org http://quozl.netrek.org/

[Javier Cardona]

Don't have a box with me right now to confirm, but this command
sequence used to turn off the radio:

# killall NetworkManager
# iwpriv eth0 radiooff

Javier

On 9/17/07, James Cameron <***@laptop.org> wrote:
> Low priority ... removing the usb8xxx kernel driver is not a
> conventional use case.
>
> On Mon, Sep 17, 2007 at 10:32:35PM -0400, Bernardo Innocenti wrote:
> > I don't see how removing the usb8xxx kernel driver may affect X client
> > connections. I'd say the two have to be independent.
>
> I agree. But it happens. I've reproduced it. I'll try some later
> builds though. 566 is a bit old now. Sorry.
>
> > Where do you see this message?
>
> By pressing Control/Alt/F2. The X server /usr/bin/X has file descriptor
> 2 (stderr) anchored to /dev/tty2, per "ls -l /proc/`pgrep X`/fd" ...
> therefore the second text console contains the message, repeating.
>
> > Check for $XAUTHORITY: it should point to a file containing the xauth
> > cookie.
>
> Got it. /proc/`pgrep X`/environ contains XAUTHORITY which points to
> /home/olpc/.Xauthority last changed several days ago, which contains a
> hostname of xo-05-27-F1.localdomain, but the current /bin/hostname
> output is "localhost.localdomain" ... so I conjecture that removing the
> wireless kernel driver results in the hostname not being the same as
> what it was before.
>
> --
> James Cameron mailto:***@us.netrek.org http://quozl.netrek.org/
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>


--
Javier Cardona
cozybit Inc.

[James Cameron]

On 18/09/2007, at 2:20 PM, Javier Cardona wrote:
> Don't have a box with me right now to confirm, but this command
> sequence used to turn off the radio:
>
> # killall NetworkManager

This seems to. The LEDs are extinguished. However it turns back on
after the next reboot.

> # iwpriv eth0 radiooff

This generates "Invalid command : radiooff" on build 566.

--
James Cameron

[Bernardo Innocenti]

James Cameron wrote:

> By pressing Control/Alt/F2. The X server /usr/bin/X has file descriptor
> 2 (stderr) anchored to /dev/tty2, per "ls -l /proc/`pgrep X`/fd" ...
> therefore the second text console contains the message, repeating.

This behavior comes from olpc-dm... Actually I don't like it that
much... I preferred $HOME/.xsession-errors.


> Got it. /proc/`pgrep X`/environ contains XAUTHORITY which points to
> /home/olpc/.Xauthority last changed several days ago, which contains a
> hostname of xo-05-27-F1.localdomain, but the current /bin/hostname
> output is "localhost.localdomain" ... so I conjecture that removing the
> wireless kernel driver results in the hostname not being the same as
> what it was before.

Ah, good catch!

But it's suspicious that .Xauthority is that old, because a fresh one
should be created each time X starts. Is the hwclock set correctly?

In latest builds, the cookies moved to ~/.serverauth.$$.

I dunno why we put the PID there. It litters the home directory.
Auth cookies are unique per-display, so ".xserverauth.$DISPLAY"
would have been a better name.

--
// Bernardo Innocenti - http://www.codewiz.org/
\X/ One Laptop Per Child - http://www.laptop.org/

[Hal Murray]

What are the rules about WiFi on airplanes? Do we need a solid way to turn
off the RF before it's OK to use an XO on an airplane?


Suppose I'm someplace where I don't expect or want to do any mesh networking.
How much would turning off the radio help battery life?



--
These are my opinions, not necessarily my employer's. I hate spam.

[James Cameron]

On Mon, Sep 17, 2007 at 09:22:32PM -0700, Hal Murray wrote:
> What are the rules about WiFi on airplanes?

Check with your airplane.

> Do we need a solid way to turn off the RF before it's OK to use an XO
> on an airplane?

Our target market usually won't have this problem.

> Suppose I'm someplace where I don't expect or want to do any mesh
> networking.
> How much would turning off the radio help battery life?

Last I checked, the effect was very small. There will be occasional
scans as the unit hunts around for nearby radios. One could save more
by making those scans back off rather than provide a UI element.

--
James Cameron mailto:***@us.netrek.org http://quozl.netrek.org/

[John Watlington]

>> Suppose I'm someplace where I don't expect or want to do any mesh
>> networking.
>> How much would turning off the radio help battery life?
>
> Last I checked, the effect was very small. There will be occasional
> scans as the unit hunts around for nearby radios. One could save more
> by making those scans back off rather than provide a UI element.

We see 700 to 800 mW consumed by the mesh interface, and as with most
WiFi interfaces, receiving consumes as much power as transmitting.

While it makes sense to turn off the wireless networking interface on
developer
machines, we are hesitant to add this to the UI. We are really
relying on laptops
to extend the mesh away from the school.

wad

[Mike C. Fletcher]

John Watlington wrote:
>>> Suppose I'm someplace where I don't expect or want to do any mesh
>>> networking.
>>> How much would turning off the radio help battery life?
>>>
>> Last I checked, the effect was very small. There will be occasional
>> scans as the unit hunts around for nearby radios. One could save more
>> by making those scans back off rather than provide a UI element.
>>
>
> We see 700 to 800 mW consumed by the mesh interface, and as with most
> WiFi interfaces, receiving consumes as much power as transmitting.
>
Isn't that about 1/2 of our total power budget? .7 to .8 W on a < 2W
machine? I'd thought the Marvell chip was supposed to be down in the
.3W range. Obviously haven't been following the hardware closely
enough. (http://wiki.laptop.org/go/Power_Management is where I got the
.3W idea). Is that .7W something we'll be able to bring down with
software to reduce collisions or the like? University of Toronto's
system's group has algorithms that optimise for power savings by
reducing collisions, if that would help.

[Jim Gettys]

On Tue, 2007-09-18 at 12:12 -0400, Mike C. Fletcher wrote:
> John Watlington wrote:
> >>> Suppose I'm someplace where I don't expect or want to do any mesh
> >>> networking.
> >>> How much would turning off the radio help battery life?
> >>>
> >> Last I checked, the effect was very small. There will be occasional
> >> scans as the unit hunts around for nearby radios. One could save more
> >> by making those scans back off rather than provide a UI element.
> >>
> >
> > We see 700 to 800 mW consumed by the mesh interface, and as with most
> > WiFi interfaces, receiving consumes as much power as transmitting.
> >
> Isn't that about 1/2 of our total power budget? .7 to .8 W on a < 2W
> machine? I'd thought the Marvell chip was supposed to be down in the
> .3W range. Obviously haven't been following the hardware closely
> enough. (http://wiki.laptop.org/go/Power_Management is where I got the
> .3W idea). Is that .7W something we'll be able to bring down with
> software to reduce collisions or the like? University of Toronto's
> system's group has algorithms that optimise for power savings by
> reducing collisions, if that would help.

The current firmware has not yet been optimized, and is consuming much
more power than it should once that is done. And future wireless will
also help.
- Jim

--
Jim Gettys
One Laptop Per Child

[Dan Williams]

On Tue, 2007-09-18 at 12:12 -0400, Mike C. Fletcher wrote:
> John Watlington wrote:
> >>> Suppose I'm someplace where I don't expect or want to do any mesh
> >>> networking.
> >>> How much would turning off the radio help battery life?
> >>>
> >> Last I checked, the effect was very small. There will be occasional
> >> scans as the unit hunts around for nearby radios. One could save more
> >> by making those scans back off rather than provide a UI element.
> >>
> >
> > We see 700 to 800 mW consumed by the mesh interface, and as with most
> > WiFi interfaces, receiving consumes as much power as transmitting.
> >
> Isn't that about 1/2 of our total power budget? .7 to .8 W on a < 2W
> machine? I'd thought the Marvell chip was supposed to be down in the
> .3W range. Obviously haven't been following the hardware closely

The .3W number is applicable to _infrastructure_ mode with the Marvell
part, because the device (like most 802.11 devices) can go into
powersave poll mode when in a BSS. In ad-hoc situations, of course,
there is no central controller buffering frames and sending out the TIM
and therefore you have to have your RX pieces powered on most of the
time to receive traffic from other stations, or you start missing frames
entirely. You can't use the same powersave algorithms in a mesh (or
adhoc even) network as you can use in an infrastructure network. Of
course everything in the world right now pretty much uses infrastructure
networks, and so the powersave algorithms are tuned for that. But mesh
requires new powersave algorithms, or at least an implementation of
existing algorithms. There's enough work getting the mesh implemented
and working well right now without throwing power algorithms into the
mix.

Dan

> enough. (http://wiki.laptop.org/go/Power_Management is where I got the
> .3W idea). Is that .7W something we'll be able to bring down with
> software to reduce collisions or the like? University of Toronto's
> system's group has algorithms that optimise for power savings by
> reducing collisions, if that would help.
>
>

[Richard A. Smith]

John Watlington wrote:

> While it makes sense to turn off the wireless networking interface on
> developer

So there's a slight problem with powering off the wireless interface
from an electrical standpoint. You can't.
At least not if you want a working system.

WLAN_EN controls WLAN_3.3V. +3.3V is derived from WLAN_3.3V. So if you
drop WLAN_3.3V you lose +3.3V and you also lose:

VDDIO on the LX700
Pullups on the PCI bus.
Pullups on the jtag lines
Supply voltages for COREPLL, GLPLL, and DOTPLL on the LX700
Power supply to the LX700 Therm alarm circuits
Power supply to the system clock chip.

And lots of other stuff...you get the idea. System no workie.

That leaves 3 alternatives:

1 Don't load the wlan firmware.
2 Load the firmware and tell wlan xmit to shutdown
3 Hold the WLAN module in reset.

#3 Can be done via the EC but there's currently not a command to _hold_
it in reset. There is a reset WLAN command which will strobe the reset
line for 1ms. I can add enable/disable reset commands if 1 and 2 are
not viable.

--
Richard Smith <***@laptop.org>
One Laptop Per Child

[Dan Williams]

On Tue, 2007-09-18 at 15:33 -0400, Richard A. Smith wrote:
> John Watlington wrote:
>
> > While it makes sense to turn off the wireless networking interface on
> > developer
>
> So there's a slight problem with powering off the wireless interface
> from an electrical standpoint. You can't.
> At least not if you want a working system.
>
> WLAN_EN controls WLAN_3.3V. +3.3V is derived from WLAN_3.3V. So if you
> drop WLAN_3.3V you lose +3.3V and you also lose:
>
> VDDIO on the LX700
> Pullups on the PCI bus.
> Pullups on the jtag lines
> Supply voltages for COREPLL, GLPLL, and DOTPLL on the LX700
> Power supply to the LX700 Therm alarm circuits
> Power supply to the system clock chip.
>
> And lots of other stuff...you get the idea. System no workie.
>
> That leaves 3 alternatives:
>
> 1 Don't load the wlan firmware.
> 2 Load the firmware and tell wlan xmit to shutdown
> 3 Hold the WLAN module in reset.
>
> #3 Can be done via the EC but there's currently not a command to _hold_
> it in reset. There is a reset WLAN command which will strobe the reset
> line for 1ms. I can add enable/disable reset commands if 1 and 2 are
> not viable.

1 and 2 are certainly viable and should be the preferred methods I
think. Note that right now trying to rmmod usb8xxx panics the kernel
for some reason.

Dan

[l***@yokoy.de]

moin,

On Tue, 18 Sep 2007 14:42:51 +1000
James Cameron <***@laptop.org> wrote:

> > Do we need a solid way to turn off the RF before it's OK to use an XO
> > on an airplane?
>
> Our target market usually won't have this problem.

Yes, but the developers need a solid way to switch of the RF. The Test XO target market are developers and sometimes they travel by air.

Javier wrote:
# killall NetworkManager
# iwpriv eth0 radiooff

How could we ensure not bringing up the RF at boot time? Which file takes care of this at fedora systems?

[Dan Williams]

On Tue, 2007-09-18 at 18:52 +0200, ***@yokoy.de wrote:
> moin,
>
> On Tue, 18 Sep 2007 14:42:51 +1000
> James Cameron <***@laptop.org> wrote:
>
> > > Do we need a solid way to turn off the RF before it's OK to use an XO
> > > on an airplane?
> >
> > Our target market usually won't have this problem.
>
> Yes, but the developers need a solid way to switch of the RF. The Test XO target market are developers and sometimes they travel by air.
>
> Javier wrote:
> # killall NetworkManager
> # iwpriv eth0 radiooff
>
> How could we ensure not bringing up the RF at boot time? Which file takes care of this at fedora systems?

Add a hardware killswitch if you want to be 100% sure. There is no
single file that "takes care of this" on any system really. But if you
remove the kernel modules, firmware will not get uploaded to the card,
and therefore the radio will essentially do nothing AFAIK.

Dan

[Hal Murray]

> Which laptop model?

Early B3 board in a B2 case.

> When the symptom is happening, check to see if the USB enumeration has
> changed ... I use lsusb grabbed from another system, but there's also
> something in /proc perhaps. The kernel logs should also mention
> changes to the USB device list.

I don't see any changes.

bash-3.2# /sbin/lsusb
Bus 001 Device 003: ID 13b1:0018 Linksys USB200M 10/100 Ethernet Adapter
Bus 001 Device 002: ID 1286:2001
Bus 001 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
bash-3.2#

/var/log/messages says:

Nov 25 16:09:29 localhost ntpd[1439]: kernel time sync status change 0001
Nov 25 16:26:39 localhost dhclient: DHCPREQUEST on eth1 to 192.168.1.1 port 67
Nov 25 16:27:21 localhost last message repeated 4 times
Nov 25 16:28:26 localhost last message repeated 4 times
Nov 25 16:29:29 localhost last message repeated 5 times
Nov 25 16:29:44 localhost dhclient: DHCPREQUEST on eth1 to 192.168.1.1 port 67
Nov 25 16:29:52 localhost kernel: [ 1811.351556] NETDEV WATCHDOG: eth1:
transmit timed out
Nov 25 16:29:59 localhost dhclient: DHCPREQUEST on eth1 to 192.168.1.1 port 67
Nov 25 16:30:34 localhost last message repeated 4 times
Nov 25 16:31:45 localhost last message repeated 5 times
Nov 25 16:32:55 localhost last message repeated 5 times
Nov 25 16:33:42 localhost last message repeated 4 times
Nov 25 16:33:47 localhost kernel: [ 2046.280787] NETDEV WATCHDOG: eth1:
transmit timed out
Nov 25 16:33:54 localhost dhclient: DHCPREQUEST on eth1 to 192.168.1.1 port 67
Nov 25 16:34:43 localhost last message repeated 3 times
Nov 25 16:35:48 localhost last message repeated 5 times

I read that as "something is broken", but not much help in pointing the
finger anyplace.


> Which kernel driver is being used for the USB ethernet?

[***@xo-02-33-FF ~]$ /sbin/lsmod
Module Size Used by
i2c_dev 7268 0
mousedev 11192 0
asix 16320 0
usbnet 18120 1 asix
mii 5056 2 asix,usbnet
usb8xxx 17988 0
libertas 183228 1 usb8xxx
ieee80211 32232 1 libertas
ieee80211_crypt 5664 1 ieee80211
psmouse 22636 0
serio_raw 6628 0
cs5535_gpio 4740 0
[***@xo-02-33-FF ~]$


> I suspect it has lost ability to talk to the device. Has the laptop
> gone into suspend at all since boot?

Not that I know of. I haven't run any activities or poked the power button.

The LEDs on the USB Ethernet dongle are still on.

It often keeps working long after the display gets turned off.



> This sounds like http://dev.laptop.org/ticket/4470

Maybe but it doesn't look like a good fit to me.

That bug happened on 622 (and earlier). I didn't see it with 623. It could
have been there, but if so, it happens much much less frequently.

My case might depend on which of my neighbors has their WiFi turned on.



--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

> In the past week I've noticed eth0 missing, but it came back after a
> power cycle, so I wasn't sure if it was reproducible. Now that you've
> mentioned related strangeness, I'll try harder to reproduce it.

I have a Linksys WRT54GL. I typically have 2-4 other APs visible. There are
no other XOs nearby. (At least that I know of or have ever seen on the
Neighborhood view.)

I'm running 759/760 on a B3.

I used the Wpa.sh setup script mentioned ages ago to set things up. Most of
the time, it takes a minute or 3, but it works.

Occasionally, say 1 out of 10 reboots, it doesn't work. Clicking on Connect
for my AP works.

Is there any log file or such that I can look at to get more info?



--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

> Agreed, on both F11 for XO-1 (os8) and F11 for XO-1.5 (os33). However /
> etc/cron.d has olpc specific files present.

I see olpc things in /etc/cron.d/, but I don't see any way to get to it.
/etc/crontab is empty (on my os8 on a XO-1) So is /var/spool/cron/


> F9 for XO-1 (802) uses crond for ds-backup, olpc-pwr-prof, and
> olpc-update.

Do we really want to be running something like update which (I assume) takes
significant resources without consulting with the user? I'd be grumpy if
things slowed down mysteriously, or worse if my real work got killed because
some cron job triggered OOM.


My home systems do most of their cron work in the early morning when I'm
asleep. (I leave them running 7x24.) Sometimes, I'm still up when some of
the heavy work starts running and the performance hit is annoying.

How do people with laptops handle cron jobs? I'd expect them to be turned
off at the equivalent of early morning. How/when do you do backups? updates?



--
These are my opinions, not necessarily my employer's. I hate spam.

[Daniel Drake]

2009/11/4 Hal Murray <***@megapathdsl.net>:
> Do we really want to be running something like update which (I assume) takes
> significant resources without consulting with the user?

Yes! Remember, these are not designed as normal laptops. They are for
young children and for use in schools. The only time to do updates is
when the child is at school, connected to the school server, and if
updates are not fully automatic then they simply will not happen.

Daniel

[C. Scott Ananian]

Keep in mind that some of cron's duties are done by anacron (or were
when I had a hand in the distro), which is laptop-friendly.

Anacron only handles daily/weekly/monthly tasks, though; you do need
cron running if you want tasks with sub-day scheduling.
--scott

--
( http://cscott.net/ )

[Paul Fox]

c. scott ananian wrote:
> Keep in mind that some of cron's duties are done by anacron (or were
> when I had a hand in the distro), which is laptop-friendly.
>
> Anacron only handles daily/weekly/monthly tasks, though; you do need
> cron running if you want tasks with sub-day scheduling.

as dsd pointed out to me on IRC, anacron is driven by cron -- at
least these days it seems to be. so without cron, anacron probably
won't work either. (i was under the impression they were
separate, but perhaps that's ancient history, or i was just
wrong.)

paul
=---------------------
paul fox, ***@laptop.org

[C. Scott Ananian]

On Wed, Nov 4, 2009 at 5:01 PM, Paul Fox <***@laptop.org> wrote:
> c. scott ananian wrote:
>  > Keep in mind that some of cron's duties are done by anacron (or were
>  > when I had a hand in the distro), which is laptop-friendly.
>  >
>  > Anacron only handles daily/weekly/monthly tasks, though; you do need
>  > cron running if you want tasks with sub-day scheduling.
>
> as dsd pointed out to me on IRC, anacron is driven by cron -- at
> least these days it seems to be.  so without cron, anacron probably
> won't work either.  (i was under the impression they were
> separate, but perhaps that's ancient history, or i was just
> wrong.)

That's *mostly* right. Anacron is idempotent, it just needs to be
triggered at least once a day so it can check to see if there's stuff
to do. It's invoked from initscripts/upstart at power up, and is
often invoked on resume-from-suspend as well. But if you actually
leave the machine on and unsuspended for >1 day, you need to trigger
it from cron as well to make sure it gets a chance to do its thing.

It never hurts to invoke anacron, you just need to ensure a certain
minimum frequency of invocation -- and cron is usually used to do
this. But you don't always immediately notice if cron is missing,
because anacron will still do its thing on startup, etc.
--scott

--
( http://cscott.net/ )

[James Cameron]

Being tracked.
http://dev.laptop.org/ticket/9605

--
James Cameron
http://quozl.linux.org.au/

[Martin Langhoff]

On Wed, Nov 4, 2009 at 9:21 PM, Hal Murray <***@megapathdsl.net> wrote:
> I see olpc things in /etc/cron.d/, but I don't see any way to get to it.
> /etc/crontab is empty (on my os8 on a XO-1)  So is /var/spool/cron/

Modern cron execs stuff from /etc/cron.d itself.

> Do we really want to be running something like update which (I assume) takes
> significant resources without consulting with the user?  I'd be grumpy if
> things slowed down mysteriously, or worse if my real work got killed because
> some cron job triggered OOM.

Do look at the jobs themselves. olpc-update does several things.
ds-backup checks whether we're on battery, line power, etc.

And as Daniel mentions, we can't count on 6 year olds running backups...



m
--
***@gmail.com
***@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

[Mikus Grinbergs]

>> Do we really want to be running something like update which (I assume)
>> takes significant resources without consulting with the user?
>
> Yes! Remember, these are not designed as normal laptops. They are for
> young children and for use in schools. The only time to do updates is
> when the child is at school, connected to the school server, and if
> updates are not fully automatic then they simply will not happen.

In an endeavor *completely* removed from OLPC (or the XO), I've had
a long-standing philosophy difference - I'm a "hands on" guy - and
they don't want to facilitate that. Now with regard to automatic
updates, the same philosophy difference is showing up with the XO:

Wiki page http://wiki.laptop.org/go/Update_streams describes how by
specifying 'none' as the update-stream value, updates are supposed
to be "never update me" (automatically). Yet, despite me always
having 'none' in /security/update-stream -- in 2007/2008 if I
entered 'top' I all too frequently saw 'olpc-update-query' using
system resources (uselessly, because it was unable to get through my
proxy back to any server). [I do updating with manual commands.]

Please -- do run your automatic updates to your heart's content.
But if a non-child XO user like me has specified 'none' -- DON'T run
automatic updates.


Thanks, mikus

[C. Scott Ananian]

On Wed, Nov 4, 2009 at 4:40 PM, Mikus Grinbergs <***@bga.com> wrote:
>>> Do we really want to be running something like update which (I assume)
>>> takes significant resources without consulting with the user?
>>
>> Yes! Remember, these are not designed as normal laptops. They are for
>> young children and for use in schools. The only time to do updates is
>> when the child is at school, connected to the school server, and if
>> updates are not fully automatic then they simply will not happen.
>
> In an endeavor *completely* removed from OLPC (or the XO), I've had
> a long-standing philosophy difference - I'm a "hands on" guy - and
> they don't want to facilitate that.  Now with regard to automatic
> updates, the same philosophy difference is showing up with the XO:
>
> Wiki page http://wiki.laptop.org/go/Update_streams  describes how by
> specifying 'none' as the update-stream value, updates are supposed
> to be "never update me" (automatically).  Yet, despite me always
> having 'none' in /security/update-stream -- in 2007/2008 if I
> entered 'top' I all too frequently saw 'olpc-update-query' using
> system resources (uselessly, because it was unable to get through my
> proxy back to any server).  [I do updating with manual commands.]
>
> Please -- do run your automatic updates to your heart's content.
> But if a non-child XO user like me has specified 'none' -- DON'T run
> automatic updates.

Mikus: olpc-update-query should be launching, seeing your 'none'
stream, and immediately exiting. It's just a software maintenance
issue that it launches at all; cron doesn't allow conditionals in
crontab. I don't have the source handy, but I suspect I implemented
'none' server side just to avoid cluttering up the client code with
special cases, but I'm sure a patch would be accepted to do early exit
on 'none' if you'd like to write one.
--scott

--
( http://cscott.net/ )

[Hal Murray]

***@laptop.org said:
>> But the network doesn't come back.
>> I was expecting it to reconnect to my AP.
> Nothing to do with #10402. Continue to investigate.

It works with GNOME so I expect Sugar is missing a few lines of code.
http://bugs.sugarlabs.org/ticket/2808

-----------

Speaking of WiFi...

My /var/log/messages has several clumps of things like this:
Apr 27 01:46:12 xo-0d-57-33 kernel: [ 2510.094064] libertas: submit
802_11_GET_LOG (#10748 diag)
grep finds 566 in about an hour

I've also got one of these:
Apr 27 01:54:24 xo-0d-57-33 kernel: [ 2998.013473] ------------[ cut here
]------------
Apr 27 01:54:24 xo-0d-57-33 kernel: [ 2998.018132] WARNING: at
net/sched/sch_generic.c:258 dev_watchdog+0xf0/0x176()
Apr 27 01:54:24 xo-0d-57-33 kernel: [ 2998.025368] Hardware name: XO
Apr 27 01:54:24 xo-0d-57-33 kernel: [ 2998.028346] NETDEV WATCHDOG: eth0
(usb): transmit queue 0 timed out
...

Does anybody want those log files? If so, who? ...



--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

***@laptop.org said:
> The build number meaning has become overloaded. I dislike having it
> exposed.

You have to expose something that's unique for each build so you can talk
about which versions do/don't have a particular bug or feature.

I think a sequential number is about as good as you are going to get. It
lets you use "before" and "after".



--
These are my opinions, not necessarily my employer's. I hate spam.

[Hal Murray]

> http://wiki.laptop.org/go/OLPC_Firmware_q2f10

That says:

> * if the downloaded file is on a USB drive, type:
> ok flash u:\q2f10.rom

But that didn't work for me.

It does work if I use "disk:" rather than "u:".

Is that wiki page simply out of date? If so, what changed...? Or is
something more complicated going on?


--
These are my opinions, not necessarily my employer's. I hate spam.

[James Cameron]

On Tue, May 01, 2012 at 12:26:57AM -0700, Hal Murray wrote:
> > http://wiki.laptop.org/go/OLPC_Firmware_q2f10
>
> That says:
>
> > * if the downloaded file is on a USB drive, type:
> > ok flash u:\q2f10.rom
>
> But that didn't work for me.
>
> It does work if I use "disk:" rather than "u:".

Interesting. What firmware version do you have installed at the moment?

> Is that wiki page simply out of date? If so, what changed...? Or is
> something more complicated going on?

The Wiki page is correct, and "flash u:\q2f10.rom" works for me. I'd
like to know what changed to make it not work for you.

--
James Cameron
http://quozl.linux.org.au/

[Hal Murray]

***@laptop.org said:
>> It does work if I use "disk:" rather than "u:".
> Interesting. What firmware version do you have installed at the moment?

I'm not sure what I had since I have "fixed" that by updating it to q2f10.rom
. Most likely it was the previously announced version.


Running q2f10.rom with that USB Flash drive plugged in...

ok dir u: says "Can't open directory"
ok dir disk: says
fat-file-system
(and files/dirs I that seem reasonable, including q2f10.rom that I loaded.)

In case it matters, this USB drive is old, old, old... 16 MB. :)


--
These are my opinions, not necessarily my employer's. I hate spam.

[James Cameron]

On Tue, May 01, 2012 at 02:10:28AM -0700, Hal Murray wrote:
> Running q2f10.rom with that USB Flash drive plugged in...
>
> ok dir u: says "Can't open directory"
> ok dir disk: says
> fat-file-system
> (and files/dirs I that seem reasonable, including q2f10.rom that I loaded.)
>
> In case it matters, this USB drive is old, old, old... 16 MB. :)

Ah, right, I can guess what might be going on. The device is not
available soon enough after the bus is probed.

When you type "dir u:" and press enter, the USB bus is probed first,
then the device is accessed.

When you type "dir disk:" and press enter, the device is accessed
without a USB bus probe.

You might work around this problem with that USB drive by either:

1. plugging in the USB drive before starting Open Firmware, and then
using "disk:" in place of "u:", or

2. plugging in the USB drive after starting Open Firmware, using
"probe-usb" first (which can be abbreviated to "p2"), then using "disk:"
in place of "u:".

You might determine the time required for the device to settle by adding
a delay between probe and access.

ok probe-usb d# 500 ms dir disk:

If that works, lower the delay until it does not. Otherwise increase
the delay. The delay is in decimal milliseconds.

I've looked through the changes from Q2F08 to Q2F09 for anything that
might have caused this. There is nothing obvious.

I've looked through the changes from Q2F09 to Q2F10 for anything that
might have caused this. There is one tiny change in svn 2943 that
removes UFS partition support, and this _may_ have led to less elapsed
time between probe and access. But this does not explain what you saw
before the upgrade.

The USB drive may respond differently over time due to changes to the
flash cells.

--
James Cameron
http://quozl.linux.org.au/

[Hal Murray]

> ok dir u: says "Can't open directory"
> In case it matters, this USB drive is old, old, old... 16 MB. :)

I took the discussion with James Cameron off-list to reduce clutter.

For the archives and/or in case anybody is curious.

The problem turned out to be that dir u: doesn't support USB 1.1 drives.
(Remember, I said it was old.)


--
These are my opinions, not necessarily my employer's. I hate spam.

[John Watlington]

On May 3, 2012, at 1:37 AM, Hal Murray wrote:

>> ok dir u: says "Can't open directory"
>> In case it matters, this USB drive is old, old, old... 16 MB. :)
>
> I took the discussion with James Cameron off-list to reduce clutter.
>
> For the archives and/or in case anybody is curious.
>
> The problem turned out to be that dir u: doesn't support USB 1.1 drives.
> (Remember, I said it was old.)

Just for clarification, do you mean full-speed (11 Mb/s) devices (USB 1.0) or
low-speed (1 Mb/s) devices (USB 1.1) aren't supported by dir u: ?

Cheers,
wad

[Hal Murray]

***@laptop.org said:
> To avoid it powering off, type lid-off and press enter. Yes, you only have
> eight seconds to do this.

The printout said that, but I didn't even get started typing before it timed
out.

I'm not sure where 8 seconds came from. If that happened often enough I'd
probably be able to do it fast enough. But that was the first time I had
seen it. I wasn't quick enough to read and understand and type. Remember, I
was trying to not destroy the evidence so I was going slowly.

---------

Something similar happened a few months ago which is why I saved Richard's
message.

I have a hack script that reboots the XO every 4 hours. It's got a patch to
check
/sys/class/power_supply/olpc-battery/error
and log the answer instead of rebooting. The error was 20

(Sorry I didn't remember to look there earlier.)



--
These are my opinions. I hate spam.

[James Cameron]

On Fri, Aug 03, 2012 at 08:38:05PM -0700, Hal Murray wrote:
>
> ***@laptop.org said:
> > To avoid it powering off, type lid-off and press enter. Yes, you only have
> > eight seconds to do this.
>
> The printout said that, but I didn't even get started typing before
> it timed out.

Yes, but I wanted you to be ready to have to do it.

> I'm not sure where 8 seconds came from. If that happened often
> enough I'd probably be able to do it fast enough. But that was the
> first time I had seen it. I wasn't quick enough to read and
> understand and type. Remember, I was trying to not destroy the
> evidence so I was going slowly.

Sure, not a criticism, just making sure you have the tools you need.

The eight seconds comes from here:

http://tracker.coreboot.org/trac/openfirmware/browser/dev/olpc/lid.fth#L6

There's a two second delay before the message appears.

The timer starts as soon as ok is printed.

--
James Cameron
http://quozl.linux.org.au/

[Richard A. Smith]

On 08/03/2012 11:38 PM, Hal Murray wrote:

> I have a hack script that reboots the XO every 4 hours. It's got a patch to
> check
> /sys/class/power_supply/olpc-battery/error
> and log the answer instead of rebooting. The error was 20
>
> (Sorry I didn't remember to look there earlier.)

20 is 0x14 which is bank zero error. I think you are the 2nd person to
report a transient bank 0 problem. Thats odd since I would expect a
bank 0 error to be permanent. The code does several re-reads before
giving up and throwing the error.

[Hal Murray]

***@laptop.org said:
> "date" followed by a successful normal shutdown should work, because a
> normal shutdown runs hwclock ... but "hwclock --systohc" is handy in case
> you aren't sure that a normal shutdown will happen next.

It used to do that on shutdown as part of /etc/rc.d/init.d/halt and friends,
but I think it got dropped as part of the switch to systemd. >grep hwclock
/etc -r< doesn't find anything.

Does anybody know if it moved to someplace I haven't looked yet and/or if it
was deliberately dropped or just fell through the cracks?


--
These are my opinions. I hate spam.

[Martin Langhoff]

On Mon, Aug 27, 2012 at 2:24 PM, Hal Murray <***@megapathdsl.net> wrote:
> ***@laptop.org said:
>> "date" followed by a successful normal shutdown should work, because a
>> normal shutdown runs hwclock ... but "hwclock --systohc" is handy in case
>> you aren't sure that a normal shutdown will happen next.
>
> It used to do that on shutdown as part of /etc/rc.d/init.d/halt and friends,
> but I think it got dropped as part of the switch to systemd. >grep hwclock
> /etc -r< doesn't find anything.
>
> Does anybody know if it moved to someplace I haven't looked yet and/or if it
> was deliberately dropped or just fell through the cracks?

You are correct, the switch to systemd means we no longer sync from
system clock to hw clock. I spotted that early, and documented it in
the release notes:
http://wiki.laptop.org/go/Release_notes/12.1.0#Base_system

I also pestered upstream (systemd) to fix ntpdate and friends. See
http://lists.freedesktop.org/archives/systemd-devel/2012-April/005023.html and
https://dev.laptop.org/ticket/11483

hth,



m
--
***@gmail.com
***@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

[Martin Langhoff]

On Tue, Aug 28, 2012 at 2:48 PM, Martin Langhoff
<***@gmail.com> wrote:
> You are correct, the switch to systemd means we no longer sync from
> system clock to hw clock. I spotted that early, and documented it in
> the release notes:
> http://wiki.laptop.org/go/Release_notes/12.1.0#Base_system

I'll also note that this is OT on this thread, which is about 11.3.x,
based on F14, with no systemd involvement.


m
--
***@gmail.com
***@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff

[Hal Murray]

***@laptop.org said:
> The problem of the unexpected lid closed power down in Open Firmware after a
> warm restart from Linux, will be fixed in the next release.

> The warm restart was not clearing an input inverter on the path from the lid
> sensor to the processor. A cold restart, using the power button or the bye
> command, was not affected.

I'm missing something. If that's the whole story, why doesn't this problem
show up on every reboot from Linux? I do that every 4 hours with only
occasional problems.

--
These are my opinions. I hate spam.

[k***@gmail.com]

The lid message happens every time to me when I reboot from Linux and immediately enter firmware on any XO1 on any build using Q2F12 or 13. I wasn't testing for any other symptoms on rebooting from Linux, just that lid message on a Linux reboot directly into firmware.

KG
------Original Message------
From: Hal Murray
Sender: devel-***@lists.laptop.org
To: James Cameron
Cc: Development List OLPC
Cc: Hal Murray
Subject: Re: Firmware issu
Sent: Sep 3, 2012 23:56


***@laptop.org said:
> The problem of the unexpected lid closed power down in Open Firmware after a
> warm restart from Linux, will be fixed in the next release.

> The warm restart was not clearing an input inverter on the path from the lid
> sensor to the processor. A cold restart, using the power button or the bye
> command, was not affected.

I'm missing something. If that's the whole story, why doesn't this problem
show up on every reboot from Linux? I do that every 4 hours with only
occasional problems.

--
These are my opinions. I hate spam.



_______________________________________________
Devel mailing list
***@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Sent from my BlackBerry device on the Roge

[Hal Murray]

***@gmail.com said:
> The lid message happens every time to me when I reboot from Linux and
> immediately enter firmware on any XO1 ...

Ah, thanks... I didn't catch the whole recipe.

It's Linux, reboot, ESC to OFW that shows the problem.
I just got it first try.

I'm normally doing lots of Linux reboot to Linux (without going to the OFW
prompt).


--
These are my opinions. I hate spam.

[James Cameron]

On Tue, Sep 04, 2012 at 01:23:31AM -0700, Hal Murray wrote:
> ***@gmail.com said:
> > The lid message happens every time to me when I reboot from Linux and
> > immediately enter firmware on any XO1 ...
>
> Ah, thanks... I didn't catch the whole recipe.
>
> It's Linux, reboot, ESC to OFW that shows the problem.
> I just got it first try.
>
> I'm normally doing lots of Linux reboot to Linux (without going to the OFW
> prompt).

Exactly, it is a rare dance that leads to the misstep. It's not a
critical problem for a child end-user, but it will be noticed by
people who want to reboot out of Linux into Open Firmware.

--
James Cameron
http://quozl.linux.org.au/

[Hal Murray]

> * try a different USB drive,

I wore out a USB drive, just by downloading new versions of XO-1.0 software
to try. (Kingston, 2GB)

copy-nand complained. I forget the exact error message, but it was obvious
after I compared the bits on the USB drive against the bits on the disk.

Many thanks for the CRC checking part of copy-nand.


I still have the busted USB drive if anybody wants one that is
just-flakey-enough for testing.



--
These are my opinions. I hate spam.

[James Cameron]

I'm a bit interested. I haven't been able to make any of mine fail,
and I've a collection of about twelve so far, accumulated over ten
years.

I've always found my problems to be either:

- invalid partitioning,

- unrepeatable corruption of the partition table or filesystem, or;

- physical wear on the connectors,

- plastic dimensions that prevent full insertion.

On Wed, Jun 12, 2013 at 11:03:20PM -0700, Hal Murray wrote:
>
> > * try a different USB drive,
>
> I wore out a USB drive, just by downloading new versions of XO-1.0 software
> to try. (Kingston, 2GB)
>
> copy-nand complained. I forget the exact error message, but it was obvious
> after I compared the bits on the USB drive against the bits on the disk.
>
> Many thanks for the CRC checking part of copy-nand.
>
>
> I still have the busted USB drive if anybody wants one that is
> just-flakey-enough for testing.
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel

--
James Cameron
http://quozl.linux.org.au/

[Hal Murray]

***@laptop.org said:
> A better measurement to look for is the elapsed time of activity startup.
> This is a most interesting value, but it is difficult to obtain without
> changing the activity source so that the point of startup completion is
> identified. (That task is made more difficult since some activities
> schedule some of their startup _after_ their main startup.)

Would it be worth adding a small chunk of code to Sugar to help this area?
I'm thinking of an API to say "OK, I'm really started now." so Sugar can log
a line of data on how long it took to get started.

There should probably be an environment variable to or similar enable that
performance logging.


--
These are my opinions. I hate spam.

[James Cameron]

On Thu, Jul 04, 2013 at 06:06:53PM -0700, Hal Murray wrote:
>
> ***@laptop.org said:
> > A better measurement to look for is the elapsed time of activity startup.
> > This is a most interesting value, but it is difficult to obtain without
> > changing the activity source so that the point of startup completion is
> > identified. (That task is made more difficult since some activities
> > schedule some of their startup _after_ their main startup.)
>
> Would it be worth adding a small chunk of code to Sugar to help this
> area? I'm thinking of an API to say "OK, I'm really started now."
> so Sugar can log a line of data on how long it took to get started.
>
> There should probably be an environment variable to or similar
> enable that performance logging.

Looks like that is what Gonzalo has posted?

--
James Cameron
http://quozl.linux.org.au/

[Hal Murray]

***@laptop.org said:
> Hmm, there should be, though it might be the word "English" in another
> language.

There are 3 choices on the pull-down list. They look like the same 3 I had
before. The format is things like:
Kreyol (Haiti)
but the stuff inside () is useless (to me) for Dari and Pashto.

There is no circle-minus box available. It doesn't even tell me what the
current language is.

Anybody know where that selection is stored so I can edit it with a text
editor?


--
These are my opinions. I hate spam.

[Jerry Vonau]

On Mon, 2013-08-19 at 23:34 -0700, Hal Murray wrote:
> ***@laptop.org said:
> > Hmm, there should be, though it might be the word "English" in another
> > language.
>
> There are 3 choices on the pull-down list. They look like the same 3 I had
> before. The format is things like:
> Kreyol (Haiti)
> but the stuff inside () is useless (to me) for Dari and Pashto.
>
> There is no circle-minus box available. It doesn't even tell me what the
> current language is.
>
> Anybody know where that selection is stored so I can edit it with a text
> editor?
>
>
/home/olpc/.i18n

Jerry

[Walter Bender]

Could you please file a ticket with the output of shell.log? I'll take
a look (having been the last one to touch those bits). Thx.

-walter

On Tue, Aug 20, 2013 at 2:34 AM, Hal Murray <***@megapathdsl.net> wrote:
>
> ***@laptop.org said:
>> Hmm, there should be, though it might be the word "English" in another
>> language.
>
> There are 3 choices on the pull-down list. They look like the same 3 I had
> before. The format is things like:
> Kreyol (Haiti)
> but the stuff inside () is useless (to me) for Dari and Pashto.
>
> There is no circle-minus box available. It doesn't even tell me what the
> current language is.
>
> Anybody know where that selection is stored so I can edit it with a text
> editor?
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel



--
Walter Bender
Sugar Labs
http://www.sugarlabs.org

[Hal Murray]

***@laptop.org said:
> The XO-4 display has a much brighter backlight. It proved impossible to
> find such dark LEDs as used to exist.

Do they take more power or are they more efficient?



--
These are my opinions. I hate spam.

[James Cameron]

On Sun, Apr 24, 2016 at 05:53:19PM -0700, Hal Murray wrote:
> ***@laptop.org said:
> > The XO-4 display has a much brighter backlight. It proved
> > impossible to find such dark LEDs as used to exist.

I was hasty. Let me restate that. Some XO-1.75 and many XO-4,
especially those produced last year and onwards, have a different
backlight.

Look at the BL manufacturing tag in the firmware SPI Flash to figure
out if you have the new backlight source.

https://dev.laptop.org/ticket/12854 has technical details.

> Do they take more power or are they more efficient?

Probably yes to both, but I've not tested.

(i.e. more power, more efficient, more lumens overall, more lumens per watt).

--
James Cameron
http://quozl.netrek.org/

[Hal Murray]

> Better would be to use SD cards.

The original goal was to copy microSD cards.

Would it be reasonable to copy microSD to SD, move the SD card to the target
XO, and then copy SD to microSD? I expect an OpenFirmware wizard could do it
with no effort but I'm not that level of wizard.

--
These are my opinions. I hate spam.

[James Cameron]

On Mon, Feb 19, 2018 at 10:13:51PM -0800, Hal Murray wrote:
> > Better would be to use SD cards.
>
> The original goal was to copy microSD cards.

Yes, but original goal unwise; it will damage the microSD card
connector and display cable. At this stage of life there is
contact oxidation, spring tension reduction, and brittle polymers.

I've observed these in my test units that have had way less use than
units in the hands of children.

> Would it be reasonable to copy microSD to SD, move the SD card to
> the target XO, and then copy SD to microSD? I expect an
> OpenFirmware wizard could do it with no effort but I'm not that
> level of wizard.

No, not really.

An order of magnitude faster to use Linux to copy, as it can do
asynchronous I/O. Open Firmware only does asynchronous I/O during
fs-update.

To access my wizardry, use the tools we have refined and kept running
for years, or get me to do it. Can also sign the build; overcomes the
next common problem; locked laptops.

The .zd format and fs-update is the fastest method to bulk load the
microSD card without having to remove and replace it.

A clone can be made with Linux, then converted to .zd using the
zhashfs program.

There is also rsync from a teacher laptop, see
http://wiki.laptop.org/go/Tiny_Core_Linux/Reversion

--
James Cameron
http://quozl.netrek.org/