Discussion:
Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend
Ajay Garg
2012-04-29 07:26:17 UTC
Permalink
Hi all.

To be absolutely clear in communicating my query, I will list the history
of the issue ::


a)
The original issue was that when XO-1s were booted, no wireless/ad-hoc
icons could be seen in the Neighborhood-View. This happened on intermediate
basis.


b)
Upon some debugging, it was found that for the failure cases, "olpc-mesh
device" was being identified in the context of NetworkManager, even though
"echo 0 > "/sys/class/net/eth0/lbs_mesh"" workaround had been integrated
into "/etc/rc.d/rc.local".


c)
Now, this conflict (that the script intended to disable mesh, but
Networkmanager still picked up mesh-device) caused NetworkManager to crash
(randomly). Whenever this happened, no wireless/ad-hoc icons could be seen
in the Neighborhood-View.


d)
So, the solution that was devised, was to place "echo 0 >
"/sys/class/net/eth0/lbs_mesh"" script, right at the beginning of "start()"
method in "/etc/init.d/NetworkManager" script, so that the bootstrap
script, could be executed BEFORE the NetworkManager itself started. This
worked like a charm !!


e)
However, now, what we are seeing is that during "resume-from-suspend", the
mesh-hardware is again being picked up by the NetworkManager, thus again
causing the crash; thus again causing the icons to disappear from the
Neighborhood view. Note that, this is happening in spite of placing the
bottstrap mesh-disable script in the "start()" method of
"/etc/init.d/NetworkManager". Also to be noted, that during reboot, things
work fine (obviously).



So, the question arises, is there a different mechanism of handling of
NetworkManager, during "reboot" and "resume-from-suspend"?




For brevity, I am attaching the contents of "/etc/init.d/NetworkManager"
during the resume-from-suspend failed-case ::

####################################################################################################################
Apr 29 02:43:59 xo-05-2a-1f kernel: imklog 4.6.3, log source = /proc/kmsg
started.
Apr 29 02:43:59 xo-05-2a-1f rsyslogd: [origin software="rsyslogd"
swVersion="4.6.3" x-pid="589" x-info="http://www.rsyslog.com"] (re)start
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Linux version
2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9 (***@sinistra.laptop.org) (gcc
version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 PREEMPT Wed Oct 5
14:05:52 EDT 2011
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] BIOS-provided physical
RAM map:
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] BIOS-e801:
0000000000000000 - 000000000009f000 (usable)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] BIOS-e801:
0000000000100000 - 000000000e813c00 (usable)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Notice: NX (Execute
Disable) protection missing in CPU or disabled in BIOS!
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] DMI 2.1 present.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] last_pfn = 0xe813
max_arch_pfn = 0x100000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] init_memory_mapping:
0000000000000000-000000000e813000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] RAMDISK: 0e813e00 -
0ec00000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Allocated new RAMDISK:
007d9000 - 00bc5200
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Move RAMDISK from
000000000e813e00 - 000000000ebfffff to 007d9000 - 00bc51ff
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] 232MB LOWMEM available.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] mapped low ram: 0 -
0e813000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] low ram: 0 - 0e813000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] node 0 low ram:
00000000 - 0e813000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] node 0 bootmap
00001000 - 00002d04
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] (6/32 early
reservations) ==> bootmem [0000000000 - 000e813000]
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #0 [0000400000 -
00007d4300] TEXT DATA BSS ==> [0000400000 - 00007d4300]
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #1 [000009fc00 -
0000100000] BIOS reserved ==> [000009fc00 - 0000100000]
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #2 [00007d5000 -
00007d80cc] BRK ==> [00007d5000 - 00007d80cc]
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #3 [0000007000 -
0000008000] PGTABLE ==> [0000007000 - 0000008000]
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #4 [00007d9000 -
0000bc6000] NEW RAMDISK ==> [00007d9000 - 0000bc6000]
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #5 [0000001000 -
0000003000] BOOTMAP ==> [0000001000 - 0000003000]
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Zone PFN ranges:
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] DMA 0x00000001 ->
0x00001000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Normal 0x00001000 ->
0x0000e813
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Movable zone start PFN
for each node
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] early_node_map[2] active
PFN ranges
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] 0: 0x00000001 ->
0x0000009f
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] 0: 0x00000100 ->
0x0000e813
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Allocating PCI resources
starting at e813c00 (gap: e813c00:f17ec400)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Built 1 zonelists in
Zone order, mobility grouping on. Total pages: 58848
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Kernel command line:
no_console_suspend selinux=0 ro console=ttyS0,115200 console=tty0
fbcon=font:SUN12x22
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] PID hash table entries:
1024 (order: 0, 4096 bytes)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Dentry cache hash table
entries: 32768 (order: 5, 131072 bytes)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Inode-cache hash table
entries: 16384 (order: 4, 65536 bytes)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Initializing CPU#0
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Memory: 227200k/237644k
available (2442k kernel code, 10052k reserved, 995k data, 240k init, 0k
highmem)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] virtual kernel memory
layout:
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] fixmap : 0xfffe5000
- 0xfffff000 ( 104 kB)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] vmalloc : 0xcf013000
- 0xfffe3000 ( 783 MB)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] lowmem : 0xc0000000
- 0xce813000 ( 232 MB)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] .init : 0xc075c000
- 0xc0798000 ( 240 kB)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] .data : 0xc0662b18
- 0xc075b76c ( 995 kB)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] .text : 0xc0400000
- 0xc0662b18 (2442 kB)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Checking if this
processor honours the WP bit even in supervisor mode...Ok.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Hierarchical RCU
implementation.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] RCU-based detection
of stalled CPUs is disabled.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Verbose stalled-CPUs
detection is disabled.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] NR_IRQS:16
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Console: colour EGA 80x25
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] console [tty0] enabled
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] console [ttyS0] enabled
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Fast TSC calibration
using PIT
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Detected 431.247 MHz
processor.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.020011] Calibrating delay loop
(skipped), value calculated using timer frequency.. 862.49 BogoMIPS
(lpj=4312470)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.032778] pid_max: default: 4096
minimum: 301
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.040211] Security Framework
initialized
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.044457] Mount-cache hash table
entries: 512
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.050437] Performance Events: no
PMU driver, software events only.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.056934] CPU: Geode(TM)
Integrated Processor by AMD PCS stepping 02
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.061782] devtmpfs: initialized
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.065903] NET: Registered protocol
family 16
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.070053] geode-mfgpt: 8 MFGPT
timers available.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.075008] geode-mfgpt: Registered
timer 0
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.080034] mfgpt-timer:
Registering MFGPT timer 0 as a clock event, using IRQ 7
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.090530] OLPC board with
OpenFirmware CL1 Q2E45 Q2E
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.098100] OLPC board revision B4
(EC=55)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.100996] PCI: Using configuration
type OLPC
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.109230] bio: create slab <bio-0>
at 0
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.110882] SCSI subsystem
initialized
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.115291] Advanced Linux Sound
Architecture Driver Version 1.0.23.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.120075] PCI: Probing PCI hardware
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.127804] Switching to clocksource
tsc
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.139255] NET: Registered protocol
family 2
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.144213] IP route cache hash
table entries: 2048 (order: 1, 8192 bytes)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.151695] TCP established hash
table entries: 8192 (order: 4, 65536 bytes)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.159102] TCP bind hash table
entries: 8192 (order: 3, 32768 bytes)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.165877] TCP: Hash tables
configured (established 8192 bind 8192)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.172310] TCP reno registered
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.175769] NET: Registered protocol
family 1
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.180587] Trying to unpack rootfs
image as initramfs...
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.224642] Freeing initrd memory:
4020k freed
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.230325] input: OLPC PM as
/devices/virtual/input/input0
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.240838] input: OLPC lid switch
as /devices/virtual/input/input1
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.247502] input: OLPC ebook switch
as /devices/virtual/input/input2
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.254436] input: OLPC AC power
jack as /devices/virtual/input/input3
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.261148] SCI is mapped to IRQ 3
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.271048] HugeTLB registered 4 MB
page size, pre-allocated 0 pages
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.278254] JFFS2 version 2.2.
(NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.385105] PROM: Built device tree
with 36735 bytes of memory.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.391269] msgmni has been set to
451
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.398593] io scheduler noop
registered
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.402838] io scheduler cfq
registered (default)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.407654] pci 0000:00:0f.0:
allocated PCI BAR #1: base 0x1000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.413821] pci 0000:00:0f.0:
cs5535-gpio: GPIO support successfully loaded.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.427606] lxfb 0000:00:01.1: 16384
KB of video memory at 0xfd000000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.562380] Console: switching to
colour frame buffer device 100x40
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.608389] fb0: Geode LX frame
buffer device
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.614263] Non-volatile memory
driver v1.3
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.619090] AMD Geode RNG detected
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.623065] Serial: 8250/16550
driver, 1 ports, IRQ sharing enabled
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.916824] serial8250: ttyS0 at I/O
0x3f8 (irq = 4) is a NS16550A
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.930412] brd: module loaded
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.933990] pci 0000:00:0f.0:
allocated PCI BAR #2: base 0x1800
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.940832] pci 0000:00:0f.0:
cs5535-mfgpt: 7 MFGPT timers available
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.950671] NAND device:
Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.963360] 2 NAND chips detected
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.969418] cmdlinepart partition
parsing not available
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.975500] Searching for RedBoot
partition table in NAND 512MiB 3,3V 8-bit at offset 0x0
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.991481] No RedBoot partition
table detected in NAND 512MiB 3,3V 8-bit
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.017369] serio: i8042 KBD port at
0x60,0x64 irq 1
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.023086] serio: i8042 AUX port at
0x60,0x64 irq 12
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.039336] rtc_cmos rtc_cmos: rtc
core: registered rtc_cmos as rtc0
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.056715] rtc0: alarms up to one
year, y3k, 242 bytes nvram
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.075113] olpc-dcon: Discovered
DCON version 2
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.094945] Linux video capture
interface: v2.00
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.204833] cpuidle: using governor
ladder
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.221547] cpuidle: using governor
menu
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.238261] sdhci: Secure Digital
Host Controller Interface driver
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.258072] sdhci: Copyright(c)
Pierre Ossman
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.276374] sdhci-pci 0000:00:0c.1:
SDHCI controller found [11ab:4101] (rev 10)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.298621] sdhci-pci 0000:00:0c.1:
Invalid iomem size. You may experience problems.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.322200] mmc0: SDHCI controller
on PCI [0000:00:0c.1] using DMA
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.353854] geode-aes: GEODE AES
engine enabled.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.376062] pci 0000:00:0f.0:
registered timer 1
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.397663] cs5535-clockevt: Unable
to set up the interrupt.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.420972] cs5535-clockevt: Unable
to set up the MFGPT clock source
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.449707] Failure reading codec
reg 0x7e,Last value=0x7e805368
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.474436] Failure reading codec
reg 0x7e,Last value=0x7e805368
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.506668] ALSA device list:
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.528479] #0: CS5535 Audio
cs5535audio at 0x1480, irq 5
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.554231] TCP bic registered
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.576507] Initializing XFRM
netlink socket
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.600118] NET: Registered protocol
family 10
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.624297] lo: Disabled Privacy
Extensions
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.647896] Mobile IPv6
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.669158] NET: Registered protocol
family 17
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.727104] input: AT Translated Set
2 keyboard as /devices/platform/i8042/serio0/input/input4
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.831995] Freeing unused kernel
memory: 240k freed
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.930413] udev[52]: starting
version 161
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 7.890087] JFFS2 notice: (126)
jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum
(0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 7.979968] dracut: Mounted root
filesystem mtd0
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 8.743653] dcon_freeze_store: 0
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 8.746916] dcon_source_switch to CPU
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 8.790427] olpc-dcon: The CPU has
control
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 8.820227] dracut: Switching root
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 9.860198] usbcore: registered new
interface driver usbfs
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 9.867361] usbcore: registered new
interface driver hub
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 9.872845] usbcore: registered new
device driver usb
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 10.606582] udev[169]: starting
version 161
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 11.130752] Marvell M88ALP01 'CAFE'
Camera Controller version 2
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 11.151279] ohci_hcd: USB 1.1 'Open'
Host Controller (OHCI) Driver
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 11.246808] cafe1000-ccic
0000:00:0c.2: enabling device (0000 -> 0002)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 11.328925] ehci_hcd: USB 2.0
'Enhanced' Host Controller (EHCI) Driver
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 11.658089] Warning! ehci_hcd should
always be loaded before uhci_hcd and ohci_hcd, not after
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.275128] psmouse serio1: OLPC
touchpad revision 0x3c
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.639344] ov7670 1-0042: chip
found @ 0x84 (cafe_ccic)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.694021] ohci_hcd 0000:00:0f.4:
OHCI Host Controller
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.699341] ohci_hcd 0000:00:0f.4:
new USB bus registered, assigned bus number 1
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.730181] ohci_hcd 0000:00:0f.4:
irq 10, io mem 0xfe01a000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.822838] input: OLPC HGPK ALPS
HGPK as /devices/platform/i8042/serio1/input/input5
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.946693] hub 1-0:1.0: USB hub
found
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.950483] hub 1-0:1.0: 4 ports
detected
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.957744] mice: PS/2 mouse device
common for all mice
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.007874] ehci_hcd 0000:00:0f.5:
EHCI Host Controller
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.031931] ehci_hcd 0000:00:0f.5:
new USB bus registered, assigned bus number 2
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.096782] ehci_hcd 0000:00:0f.5:
irq 10, io mem 0xfe01b000
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.110642] ehci_hcd 0000:00:0f.5:
USB 2.0 started, EHCI 1.00
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.158797] hub 2-0:1.0: USB hub
found
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.184539] hub 2-0:1.0: 4 ports
detected
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.510975] usb 2-1: new high speed
USB device using ehci_hcd and address 2
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.794786] lib80211: common
routines for IEEE802.11 drivers
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 14.306633] cfg80211: Calling CRDA
to update world regulatory domain
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.235815] cfg80211: World
regulatory domain updated:
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.265756] (start_freq -
end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.281348] (2402000 KHz -
2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.288465] (2457000 KHz -
2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.320133] (2474000 KHz -
2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.335105] (5170000 KHz -
5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.356386] (5735000 KHz -
5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.830108] usb8xxx: Firmware ready
event received
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.854260] libertas:
00:17:c4:05:2a:1f, fw 5.110.22p23, cap 0x000003a3
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.885590] libertas: wlan0: Marvell
WLAN 802.11 adapter
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.924370] libertas: CMD_RESP:
error 0x0002 in command reply 0x8074
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.930862] libertas: PREP_CMD:
command 0x0074 failed: 2
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.936185] usb8xxx: Firmware does
not seem to support PS mode
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.984129] libertas: CMD_RESP:
error 0x0001 in command reply 0x8043
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 16.007880] libertas: PREP_CMD:
command 0x0043 failed: 1
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 16.013210] libertas: HOST_SLEEP_CFG
failed 1
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 16.034003] usbcore: registered new
interface driver usb8xxx
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 16.531496] udev[173]: renamed
network interface wlan0 to eth0
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 20.489942] init:
ck-log-system-start main process (524) terminated with status 1
Apr 29 02:43:59 xo-05-2a-1f kernel: [ 20.970486] libertas: PREP_CMD:
unknown command 0x004e
Apr 29 02:44:00 xo-05-2a-1f NetworkManager[620]: <info> NetworkManager
(version 0.8.5.92-1.git20110927.fc14) is starting...
Apr 29 02:44:00 xo-05-2a-1f NetworkManager[620]: <info> Read config file
/etc/NetworkManager/NetworkManager.conf
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Found user 'avahi' (UID 70)
and group 'avahi' (GID 70).
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Successfully dropped root
privileges.
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: avahi-daemon 0.6.27 starting
up.
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: WARNING: No NSS support for
mDNS detected, consider installing nss-mdns!
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Successfully called chroot().
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Successfully dropped
remaining capabilities.
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Loading service file
/services/ssh.service.
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Loading service file
/services/udisks.service.
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Network interface
enumeration completed.
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Registering HINFO record
with values 'I586'/'LINUX'.
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Server startup complete.
Host name is xo-05-2a-1f.local. Local service cookie is 535333239.
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Service "xo-05-2a-1f"
(/services/udisks.service) successfully established.
Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Service "xo-05-2a-1f"
(/services/ssh.service) successfully established.
Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: <info> trying to start the
modem manager...
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> ModemManager
(version 0.4.998-1.git20110706.fc14) starting...
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
Novatel
Apr 29 02:44:01 xo-05-2a-1f polkitd[652]: started daemon version 0.98 using
authority implementation `local' version `0.98'
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin Gobi
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin MotoC
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
Samsung
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
Linktop
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
Longcheer
Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: <info> monitoring kernel
firmware directory '/lib/firmware'.
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
SimTech
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin Nokia
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin Option
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin Sierra
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
AnyData
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
Generic
Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: ifcfg-rh: Acquired
D-Bus service com.redhat.ifcfgrh1
Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: <info> Loaded plugin
ifcfg-rh: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the
NetworkManager mailing list.
Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: ifcfg-rh: parsing
/etc/sysconfig/network-scripts/ifcfg-lo ...
Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: <info> found WiFi radio
killswitch rfkill0 (at /sys/devices/platform/olpc-rfkill.0/rfkill/rfkill0)
(driver olpc-rfkill)
Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
Option High-Speed
Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: <info> found WiFi radio
killswitch rfkill1 (at /sys/devices/virtual/ieee80211/phy0/rfkill1) (driver
<unknown>)
Apr 29 02:44:02 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
Ericsson MBM
Apr 29 02:44:02 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin Huawei
Apr 29 02:44:02 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin ZTE
Apr 29 02:44:02 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin X22X
Apr 29 02:44:02 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
Wavecom
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> WiFi enabled by
radio killswitch; enabled by state file
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> WWAN enabled by
radio killswitch; enabled by state file
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> WiMAX enabled by
radio killswitch; enabled by state file
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> Networking is
enabled by state file
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <error>
[1335678242.357653] [nm-device-wifi.c:3142]
real_update_permanent_hw_address(): (eth0): unable to read permanent MAC
address (error 0)
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): driver
supports SSID scans (scan_capa 0x01).
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): new 802.11
WiFi device (driver: 'usb' ifindex: 2)
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): exported as
/org/freedesktop/NetworkManager/Devices/0
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): now managed
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 1 -> 2 (reason 2)
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): bringing up
device.
Apr 29 02:44:02 xo-05-2a-1f kernel: [ 26.368472] ADDRCONF(NETDEV_UP):
eth0: link is not ready
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): preparing
device.
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0):
deactivating device (reason: 2).
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]:
supplicant_interface_acquire: assertion `mgr_state ==
NM_SUPPLICANT_MANAGER_STATE_IDLE' failed
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> modem-manager is
now available
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <warn> bluez error getting
default adapter: The name org.bluez was not provided by any .service files
Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> Trying to start the
supplicant...
Apr 29 02:44:02 xo-05-2a-1f kernel: [ 26.831857] dcon_freeze_store: 1
Apr 29 02:44:02 xo-05-2a-1f kernel: [ 26.835120] dcon_source_switch to
DCON
Apr 29 02:44:02 xo-05-2a-1f kernel: [ 26.862356] olpc-dcon: The DCON has
control
Apr 29 02:44:03 xo-05-2a-1f olpc-switchd: starting version 47
Apr 29 02:44:03 xo-05-2a-1f olpc-switchd: will poll power sources every 10
seconds
Apr 29 02:44:03 xo-05-2a-1f olpc-switchd: found 4 switches
Apr 29 02:44:03 xo-05-2a-1f olpc-kbdshim-udev[699]: starting
olpc-kbdshim-udev version 25
Apr 29 02:44:04 xo-05-2a-1f olpc-kbdshim-udev[699]: fd 5: found keyboard
(AT Translated Set 2 keyboard) /dev/input/event4 (11:01:01)
Apr 29 02:44:04 xo-05-2a-1f olpc-kbdshim-udev[699]: fd 6: found touchpad
(OLPC HGPK ALPS HGPK) /dev/input/event5 (11:02:0d)
Apr 29 02:44:04 xo-05-2a-1f olpc-kbdshim-udev[699]: fd 7: found ebook switch
Apr 29 02:44:04 xo-05-2a-1f powerd: powerd version 47 startup at Sun Apr 29
02:44:04 UYT 2012, on XO-1
Apr 29 02:44:04 xo-05-2a-1f powerd: Linux version
2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9 (***@sinistra.laptop.org) (gcc
version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 PREEMPT Wed Oct 5
14:05:52 EDT 2011
Apr 29 02:44:04 xo-05-2a-1f powerd: olpc build: 20 Version a (Dextrose 3 Uy)
Apr 29 02:44:05 xo-05-2a-1f powerd: starting
Apr 29 02:44:05 xo-05-2a-1f powerd: configuring from /etc/powerd/powerd.conf
Apr 29 02:44:05 xo-05-2a-1f kernel: [ 29.616610] input: olpc-kbdshim
virtual input as /devices/virtual/input/input6
Apr 29 02:44:05 xo-05-2a-1f powerd: configured to never shutdown while
plugged in
Apr 29 02:44:05 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
manager state: down -> idle
Apr 29 02:44:05 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 2 -> 3 (reason 0)
Apr 29 02:44:07 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
interface state: starting -> ready
Apr 29 02:44:08 xo-05-2a-1f kernel: [ 32.020282] ip_tables: (C) 2000-2006
Netfilter Core Team
Apr 29 02:44:11 xo-05-2a-1f olpc-kbdshim-udev[699]: idle timers changed to
10 180 420
Apr 29 02:44:11 xo-05-2a-1f powerd: sleep 15, dim 180, blank 420, shutdown
after 14400
Apr 29 02:44:34 xo-05-2a-1f gnome-keyring-daemon[1030]: GLib-GIO: Using the
'memory' GSettings backend. Your settings will not be saved or shared with
other applications.
Apr 29 02:44:34 xo-05-2a-1f gnome-keyring-daemon[1030]: couldn't set
environment variable in session: The name org.gnome.SessionManager was not
provided by any .service files
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
starting connection 'Auto 001a4d2f872c'
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 3 -> 4 (reason 0)
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 1 of 5 (Device Prepare) scheduled...
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 1 of 5 (Device Prepare) started...
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 2 of 5 (Device Configure) scheduled...
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 1 of 5 (Device Prepare) complete.
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 2 of 5 (Device Configure) starting...
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 4 -> 5 (reason 0)
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation
(eth0/wireless): access point 'Auto 001a4d2f872c' has security, but secrets
are required.
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 5 -> 6 (reason 0)
Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 2 of 5 (Device Configure) complete.
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 1 of 5 (Device Prepare) scheduled...
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 1 of 5 (Device Prepare) started...
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 6 -> 4 (reason 0)
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 2 of 5 (Device Configure) scheduled...
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 1 of 5 (Device Prepare) complete.
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 2 of 5 (Device Configure) starting...
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 4 -> 5 (reason 0)
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation
(eth0/wireless): connection 'Auto 001a4d2f872c' has security, and secrets
exist. No new secrets needed.
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
'ssid' value '001a4d2f872c'
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
'scan_ssid' value '1'
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
'key_mgmt' value 'NONE'
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
'auth_alg' value 'OPEN'
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
'wep_key0' value '<omitted>'
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
'wep_tx_keyidx' value '0'
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 2 of 5 (Device Configure) complete.
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: set
interface ap_scan to 1
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
connection state: inactive -> associating
Apr 29 02:44:37 xo-05-2a-1f kernel: [ 61.900024] ADDRCONF(NETDEV_CHANGE):
eth0: link becomes ready
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
connection state: associating -> associated
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
connection state: associated -> completed
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation
(eth0/wireless) Stage 2 of 5 (Device Configure) successful. Connected to
wireless network '001a4d2f872c'.
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 3 of 5 (IP Configure Start) scheduled.
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 3 of 5 (IP Configure Start) started...
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 5 -> 7 (reason 0)
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Beginning DHCPv4 transaction (timeout in 45 seconds)
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> dhclient started
with pid 1043
Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 3 of 5 (IP Configure Start) complete.
Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: Internet Systems Consortium
DHCP Client 4.2.0-P2
Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: Copyright 2004-2010 Internet
Systems Consortium.
Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: All rights reserved.
Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: For info, please visit
https://www.isc.org/software/dhcp/
Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]:
Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: Listening on
LPF/eth0/00:17:c4:05:2a:1f
Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: Sending on
LPF/eth0/00:17:c4:05:2a:1f
Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: Sending on Socket/fallback
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> (eth0): DHCPv4
state changed nbi -> preinit
Apr 29 02:44:39 xo-05-2a-1f dhclient[1043]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 3
Apr 29 02:44:39 xo-05-2a-1f dhclient[1043]: DHCPOFFER from 192.168.1.1
Apr 29 02:44:39 xo-05-2a-1f dhclient[1043]: DHCPREQUEST on eth0 to
255.255.255.255 port 67
Apr 29 02:44:39 xo-05-2a-1f dhclient[1043]: DHCPACK from 192.168.1.1
Apr 29 02:44:39 xo-05-2a-1f dhclient[1043]: bound to 192.168.1.3 -- renewal
in 42912 seconds.
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> (eth0): DHCPv4
state changed preinit -> bound
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 4 of 5 (IP4 Configure Get) scheduled...
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 4 of 5 (IP4 Configure Get) started...
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> address
192.168.1.3
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> prefix 24
(255.255.255.0)
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> gateway
192.168.1.1
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> hostname 'dhcppc1'
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> nameserver
'203.94.243.70'
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> nameserver
'203.94.227.70'
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Scheduling stage 5
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 5 of 5 (IP Configure Commit) scheduled...
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Done scheduling
stage 5
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 4 of 5 (IP4 Configure Get) complete.
Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 5 of 5 (IP Configure Commit) started...
Apr 29 02:44:39 xo-05-2a-1f avahi-daemon[633]: Joining mDNS multicast group
on interface eth0.IPv4 with address 192.168.1.3.
Apr 29 02:44:39 xo-05-2a-1f avahi-daemon[633]: New relevant interface
eth0.IPv4 for mDNS.
Apr 29 02:44:39 xo-05-2a-1f avahi-daemon[633]: Registering new address
record for 192.168.1.3 on eth0.IPv4.
Apr 29 02:44:39 xo-05-2a-1f kernel: [ 63.333513] dcon_freeze_store: 0
Apr 29 02:44:39 xo-05-2a-1f kernel: [ 63.336778] dcon_source_switch to CPU
Apr 29 02:44:39 xo-05-2a-1f kernel: [ 63.370802] olpc-dcon: The CPU has
control
Apr 29 02:44:39 xo-05-2a-1f avahi-daemon[633]: Registering new address
record for fe80::217:c4ff:fe05:2a1f on eth0.*.
Apr 29 02:44:40 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 7 -> 8 (reason 0)
Apr 29 02:44:40 xo-05-2a-1f NetworkManager[620]: <info> Policy set 'Auto
001a4d2f872c' (eth0) as default for IPv4 routing and DNS.
Apr 29 02:44:40 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
successful, device activated.
Apr 29 02:44:40 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
Stage 5 of 5 (IP Configure Commit) complete.
Apr 29 02:52:45 xo-05-2a-1f kernel: [ 549.409614] dcon_freeze_store: 1
Apr 29 02:52:45 xo-05-2a-1f kernel: [ 549.462391] dcon_source_switch to
DCON
Apr 29 02:52:45 xo-05-2a-1f kernel: [ 549.502797] olpc-dcon: The DCON has
control
Apr 29 02:52:45 xo-05-2a-1f kernel: [ 549.649543] dcon_freeze_store: 1
Apr 29 02:52:46 xo-05-2a-1f kernel: [ 550.060415] dcon_freeze_store: 0
Apr 29 02:52:46 xo-05-2a-1f kernel: [ 550.060415] dcon_source_switch to CPU
Apr 29 02:52:46 xo-05-2a-1f kernel: [ 550.110218] olpc-dcon: The CPU has
control
Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> WiFi now disabled
by radio killswitch
Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 8 -> 2 (reason 0)
Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0):
deactivating device (reason: 0).
Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0): canceled
DHCP transaction, DHCP client pid 1043
Apr 29 02:52:52 xo-05-2a-1f kernel: [ 556.600861] usb 2-1: USB disconnect,
address 2
Apr 29 02:52:52 xo-05-2a-1f avahi-daemon[633]: Withdrawing address record
for 192.168.1.3 on eth0.
Apr 29 02:52:52 xo-05-2a-1f avahi-daemon[633]: Leaving mDNS multicast group
on interface eth0.IPv4 with address 192.168.1.3.
Apr 29 02:52:52 xo-05-2a-1f avahi-daemon[633]: Interface eth0.IPv4 no
longer relevant for mDNS.
Apr 29 02:52:52 xo-05-2a-1f avahi-daemon[633]: Withdrawing address record
for fe80::217:c4ff:fe05:2a1f on eth0.
Apr 29 02:52:52 xo-05-2a-1f avahi-daemon[633]: Withdrawing workstation
service for eth0.
Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0): now
unmanaged
Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 2 -> 1 (reason 36)
Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0): cleaning
up...
Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> radio killswitch
/sys/devices/virtual/ieee80211/phy0/rfkill1 disappeared
Apr 29 02:52:53 xo-05-2a-1f nm-dispatcher.action: Error in get_property:
Method "Get" with signature "ss" on interface
"org.freedesktop.DBus.Properties" doesn't exist#012
Apr 29 02:52:53 xo-05-2a-1f kernel: [ 557.790406] PM: Syncing filesystems
... done.
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.798137] Freezing user space
processes ... (elapsed 0.02 seconds) done.
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.826215] Freezing remaining
freezable tasks ... (elapsed 0.02 seconds) done.
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.859465] dcon_source_switch to
DCON
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.892288] olpc-dcon: The DCON has
control
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.916879] sdhci_pci_probe: Enable
PME set to 0x1a0c108
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.922242] PM: suspend of devices
complete after 62.966 msecs
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.946662] ehci_hcd 0000:00:0f.5:
Refused to change power state, currently in D0
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.976933] ohci_hcd 0000:00:0f.4:
Refused to change power state, currently in D0
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.984608] PM: late suspend of
devices complete after 56.429 msecs
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.993192] olpc_do_sleep!
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.993192] PM: early resume of
devices complete after 0.521 msecs
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.111968] usb usb1: root hub lost
power or was reset
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.133970] usb usb2: root hub lost
power or was reset
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.145371] dcon_source_switch to CPU
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.187020] olpc-dcon: The CPU has
control
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.416732] PM: resume of devices
complete after 411.146 msecs
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.422745] Restarting tasks ...
done.
Apr 29 03:11:25 xo-05-2a-1f NetworkManager[620]: <info> WiFi now enabled by
radio killswitch
Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.934219] dcon_freeze_store: 0
Apr 29 03:11:26 xo-05-2a-1f kernel: [ 558.996489] dcon_freeze_store: 0
Apr 29 03:11:26 xo-05-2a-1f kernel: [ 559.176729] usb 2-1: new high speed
USB device using ehci_hcd and address 3
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.065633] usb8xxx: Firmware ready
event received
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.092068] libertas:
00:17:c4:05:2a:1f, fw 5.110.22p23, cap 0x000003a3
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.111778] libertas: wlan0: Marvell
WLAN 802.11 adapter
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.138293] libertas: CMD_RESP:
error 0x0002 in command reply 0x8074
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.144914] libertas: PREP_CMD:
command 0x0074 failed: 2
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.150243] usb8xxx: Firmware does
not seem to support PS mode
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.208672] libertas: CMD_RESP:
error 0x0001 in command reply 0x8043
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.215439] libertas: PREP_CMD:
command 0x0043 failed: 1
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.220769] libertas: HOST_SLEEP_CFG
failed 1
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> found WiFi radio
killswitch rfkill2 (at /sys/devices/virtual/ieee80211/phy1/rfkill2) (driver
<unknown>)
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.563949] udev[1400]: renamed
network interface wlan0 to eth0
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): new 802.11
OLPC Mesh device (driver: 'usb' ifindex: 5)
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): exported as
/org/freedesktop/NetworkManager/Devices/1
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): now managed
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): device
state change: 1 -> 2 (reason 2)
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): bringing up
device.
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): preparing
device.
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0):
deactivating device (reason: 2).
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <error>
[1335679887.687698] [nm-device-wifi.c:3142]
real_update_permanent_hw_address(): (eth0): unable to read permanent MAC
address (error 0)
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): driver
supports SSID scans (scan_capa 0x01).
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): new 802.11
WiFi device (driver: 'usb' ifindex: 4)
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): exported as
/org/freedesktop/NetworkManager/Devices/2
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): now managed
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 1 -> 2 (reason 2)
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): bringing up
device.
Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.738668] ADDRCONF(NETDEV_UP):
eth0: link is not ready
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): preparing
device.
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0):
deactivating device (reason: 2).
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): device
state change: 2 -> 3 (reason 0)
Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): found
companion WiFi device eth0
Apr 29 03:11:28 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
interface state: starting -> ready
Apr 29 03:11:28 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
state change: 2 -> 3 (reason 42)
Apr 29 03:11:28 xo-05-2a-1f avahi-daemon[633]: Withdrawing workstation
service for msh0.
Apr 29 03:11:28 xo-05-2a-1f NetworkManager[620]: <info> (msh0): now
unmanaged
Apr 29 03:11:28 xo-05-2a-1f NetworkManager[620]: <info> (msh0): device
state change: 3 -> 1 (reason 36)
Apr 29 03:11:28 xo-05-2a-1f NetworkManager[620]: <info> (msh0): cleaning
up...
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: <warn> caught signal 11.
Generating backtrace...
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: ******************* START
**********************************
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 0: NetworkManager
(nm_logging_backtrace+0x56) [0x80a1536]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 1: NetworkManager
(0x8048000+0x8085ee5) [0x8085ee5]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 2: (vdso)
(__kernel_sigreturn+0x0) [0xb778b400]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 3: NetworkManager
(0x8048000+0x8076404) [0x8076404]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 4:
/lib/libgobject-2.0.so.0 (g_cclosure_marshal_VOID__PARAM+0x88) [0xb72c5588]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 5:
/lib/libgobject-2.0.so.0 (g_closure_invoke+0x193) [0xb72a8be3]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 6:
/lib/libgobject-2.0.so.0 (0xb729d000+0xb72bb0f0) [0xb72bb0f0]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 7:
/lib/libgobject-2.0.so.0 (g_signal_emit_valist+0x80e) [0xb72c424e]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 8:
/lib/libgobject-2.0.so.0 (g_signal_emit+0x33) [0xb72c4403]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 9:
/lib/libgobject-2.0.so.0 (0xb729d000+0xb72aa891) [0xb72aa891]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 10:
/lib/libgobject-2.0.so.0 (0xb729d000+0xb72a9c70) [0xb72a9c70]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 11:
/lib/libgobject-2.0.so.0 (g_object_notify+0x551) [0xb72acbe1]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 12:
/lib/libgobject-2.0.so.0 (g_cclosure_marshal_VOID__PARAM+0x88) [0xb72c5588]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 13:
/lib/libgobject-2.0.so.0 (g_closure_invoke+0x193) [0xb72a8be3]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 14:
/lib/libgobject-2.0.so.0 (0xb729d000+0xb72bb0f0) [0xb72bb0f0]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 15:
/lib/libgobject-2.0.so.0 (g_signal_emit_valist+0x80e) [0xb72c424e]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 16:
/lib/libgobject-2.0.so.0 (g_signal_emit+0x33) [0xb72c4403]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 17:
/lib/libgobject-2.0.so.0 (0xb729d000+0xb72aa891) [0xb72aa891]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 18:
/lib/libgobject-2.0.so.0 (0xb729d000+0xb72a9c70) [0xb72a9c70]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 19:
/lib/libgobject-2.0.so.0 (g_object_notify+0x551) [0xb72acbe1]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 20: NetworkManager
(0x8048000+0x80bcb6f) [0x80bcb6f]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 21:
/lib/libgobject-2.0.so.0 (g_cclosure_marshal_VOID__BOOLEAN+0x88)
[0xb72c4c88]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 22:
/usr/lib/libdbus-glib-1.so.2 (0xb74e2000+0xb74f010c) [0xb74f010c]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 23:
/lib/libgobject-2.0.so.0 (g_closure_invoke+0x193) [0xb72a8be3]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 24:
/lib/libgobject-2.0.so.0 (0xb729d000+0xb72bb0f0) [0xb72bb0f0]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 25:
/lib/libgobject-2.0.so.0 (g_signal_emit_valist+0x80e) [0xb72c424e]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 26:
/lib/libgobject-2.0.so.0 (g_signal_emit+0x33) [0xb72c4403]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 27:
/usr/lib/libdbus-glib-1.so.2 (0xb74e2000+0xb74f0d35) [0xb74f0d35]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 28:
/lib/libdbus-1.so.3 (dbus_connection_dispatch+0x393) [0xb74a4f03]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 29:
/usr/lib/libdbus-glib-1.so.2 (0xb74e2000+0xb74e920e) [0xb74e920e]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 30:
/lib/libglib-2.0.so.0 (g_main_context_dispatch+0x1d2) [0xb71bd192]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 31:
/lib/libglib-2.0.so.0 (0xb717d000+0xb71bd978) [0xb71bd978]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 32:
/lib/libglib-2.0.so.0 (g_main_loop_run+0x18b) [0xb71be04b]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 33: NetworkManager
(main+0x15d6) [0x80876b6]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 34: /lib/libc.so.6
(__libc_start_main+0xe6) [0xb6fd9e36]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 35: NetworkManager
(0x8048000+0x805df01) [0x805df01]
Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: ******************* END
**********************************
Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.307009] usb 2-2: new high speed
USB device using ehci_hcd and address 4
Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.521615] usbcore: registered new
interface driver libusual
Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.610166] Initializing USB Mass
Storage driver...
Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.619576] scsi0 : usb-storage
2-2:1.0
Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.630555] usbcore: registered new
interface driver usb-storage
Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.636943] USB Mass Storage support
registered.
Apr 29 04:20:52 xo-05-2a-1f kernel: [ 4725.663079] scsi 0:0:0:0:
Direct-Access Kingston DataTraveler 108 PMAP PQ: 0 ANSI: 0 CCS
Apr 29 04:20:52 xo-05-2a-1f kernel: [ 4725.726899] sd 0:0:0:0: Attached
scsi generic sg0 type 0
Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.416348] sd 0:0:0:0: [sda]
15646720 512-byte logical blocks: (8.01 GB/7.46 GiB)
Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.426369] sd 0:0:0:0: [sda] Write
Protect is off
Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.431204] sd 0:0:0:0: [sda]
Assuming drive cache: write through
Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.444165] sd 0:0:0:0: [sda]
Assuming drive cache: write through
Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.450419] sda: sda1
Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.473921] sd 0:0:0:0: [sda]
Assuming drive cache: write through
Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.480282] sd 0:0:0:0: [sda]
Attached SCSI removable disk
####################################################################################################################


Looking forward to some guiding light.


Regards,
Ajay
Martin Abente
2012-04-29 08:04:41 UTC
Permalink
Are you guys still using this?
http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/postresume.d/disable_mesh.sh

If so, you should remove it IF there is no way to guarantee that it will run
before NM picks up the device. At least it will avoid the crash...

I would ask in the NM community if there is a better way to disable a
particular device, like banning a device(?).

Btw, wasn't there a driver patch to disable the mesh?

On Sun, Apr 29, 2012 at 3:26 AM, Ajay Garg <***@activitycentral.com> wrote:

> Hi all.
>
> To be absolutely clear in communicating my query, I will list the history
> of the issue ::
>
>
> a)
> The original issue was that when XO-1s were booted, no wireless/ad-hoc
> icons could be seen in the Neighborhood-View. This happened on intermediate
> basis.
>
>
> b)
> Upon some debugging, it was found that for the failure cases, "olpc-mesh
> device" was being identified in the context of NetworkManager, even though
> "echo 0 > "/sys/class/net/eth0/lbs_mesh"" workaround had been integrated
> into "/etc/rc.d/rc.local".
>
>
> c)
> Now, this conflict (that the script intended to disable mesh, but
> Networkmanager still picked up mesh-device) caused NetworkManager to crash
> (randomly). Whenever this happened, no wireless/ad-hoc icons could be seen
> in the Neighborhood-View.
>
>
> d)
> So, the solution that was devised, was to place "echo 0 >
> "/sys/class/net/eth0/lbs_mesh"" script, right at the beginning of "start()"
> method in "/etc/init.d/NetworkManager" script, so that the bootstrap
> script, could be executed BEFORE the NetworkManager itself started. This
> worked like a charm !!
>
>
> e)
> However, now, what we are seeing is that during "resume-from-suspend", the
> mesh-hardware is again being picked up by the NetworkManager, thus again
> causing the crash; thus again causing the icons to disappear from the
> Neighborhood view. Note that, this is happening in spite of placing the
> bottstrap mesh-disable script in the "start()" method of
> "/etc/init.d/NetworkManager". Also to be noted, that during reboot, things
> work fine (obviously).
>
>
>
> So, the question arises, is there a different mechanism of handling of
> NetworkManager, during "reboot" and "resume-from-suspend"?
>
>
>
>
> For brevity, I am attaching the contents of "/etc/init.d/NetworkManager"
> during the resume-from-suspend failed-case ::
>
>
> ####################################################################################################################
> Apr 29 02:43:59 xo-05-2a-1f kernel: imklog 4.6.3, log source = /proc/kmsg
> started.
> Apr 29 02:43:59 xo-05-2a-1f rsyslogd: [origin software="rsyslogd"
> swVersion="4.6.3" x-pid="589" x-info="http://www.rsyslog.com"] (re)start
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Linux version
> 2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9 (***@sinistra.laptop.org) (gcc
> version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 PREEMPT Wed Oct 5
> 14:05:52 EDT 2011
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] BIOS-provided physical
> RAM map:
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] BIOS-e801:
> 0000000000000000 - 000000000009f000 (usable)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] BIOS-e801:
> 0000000000100000 - 000000000e813c00 (usable)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Notice: NX (Execute
> Disable) protection missing in CPU or disabled in BIOS!
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] DMI 2.1 present.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] last_pfn = 0xe813
> max_arch_pfn = 0x100000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] init_memory_mapping:
> 0000000000000000-000000000e813000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] RAMDISK: 0e813e00 -
> 0ec00000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Allocated new RAMDISK:
> 007d9000 - 00bc5200
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Move RAMDISK from
> 000000000e813e00 - 000000000ebfffff to 007d9000 - 00bc51ff
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] 232MB LOWMEM available.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] mapped low ram: 0 -
> 0e813000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] low ram: 0 - 0e813000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] node 0 low ram:
> 00000000 - 0e813000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] node 0 bootmap
> 00001000 - 00002d04
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] (6/32 early
> reservations) ==> bootmem [0000000000 - 000e813000]
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #0 [0000400000 -
> 00007d4300] TEXT DATA BSS ==> [0000400000 - 00007d4300]
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #1 [000009fc00 -
> 0000100000] BIOS reserved ==> [000009fc00 - 0000100000]
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #2 [00007d5000 -
> 00007d80cc] BRK ==> [00007d5000 - 00007d80cc]
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #3 [0000007000 -
> 0000008000] PGTABLE ==> [0000007000 - 0000008000]
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #4 [00007d9000 -
> 0000bc6000] NEW RAMDISK ==> [00007d9000 - 0000bc6000]
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] #5 [0000001000 -
> 0000003000] BOOTMAP ==> [0000001000 - 0000003000]
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Zone PFN ranges:
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] DMA 0x00000001
> -> 0x00001000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Normal 0x00001000
> -> 0x0000e813
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Movable zone start PFN
> for each node
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] early_node_map[2]
> active PFN ranges
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] 0: 0x00000001 ->
> 0x0000009f
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] 0: 0x00000100 ->
> 0x0000e813
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Allocating PCI
> resources starting at e813c00 (gap: e813c00:f17ec400)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Built 1 zonelists in
> Zone order, mobility grouping on. Total pages: 58848
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Kernel command line:
> no_console_suspend selinux=0 ro console=ttyS0,115200 console=tty0
> fbcon=font:SUN12x22
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] PID hash table entries:
> 1024 (order: 0, 4096 bytes)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Dentry cache hash table
> entries: 32768 (order: 5, 131072 bytes)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Inode-cache hash table
> entries: 16384 (order: 4, 65536 bytes)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Initializing CPU#0
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Memory: 227200k/237644k
> available (2442k kernel code, 10052k reserved, 995k data, 240k init, 0k
> highmem)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] virtual kernel memory
> layout:
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] fixmap :
> 0xfffe5000 - 0xfffff000 ( 104 kB)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] vmalloc :
> 0xcf013000 - 0xfffe3000 ( 783 MB)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] lowmem :
> 0xc0000000 - 0xce813000 ( 232 MB)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] .init :
> 0xc075c000 - 0xc0798000 ( 240 kB)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] .data :
> 0xc0662b18 - 0xc075b76c ( 995 kB)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] .text :
> 0xc0400000 - 0xc0662b18 (2442 kB)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Checking if this
> processor honours the WP bit even in supervisor mode...Ok.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Hierarchical RCU
> implementation.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] RCU-based detection
> of stalled CPUs is disabled.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Verbose
> stalled-CPUs detection is disabled.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] NR_IRQS:16
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Console: colour EGA
> 80x25
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] console [tty0] enabled
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] console [ttyS0] enabled
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Fast TSC calibration
> using PIT
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.000000] Detected 431.247 MHz
> processor.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.020011] Calibrating delay loop
> (skipped), value calculated using timer frequency.. 862.49 BogoMIPS
> (lpj=4312470)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.032778] pid_max: default: 4096
> minimum: 301
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.040211] Security Framework
> initialized
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.044457] Mount-cache hash table
> entries: 512
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.050437] Performance Events: no
> PMU driver, software events only.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.056934] CPU: Geode(TM)
> Integrated Processor by AMD PCS stepping 02
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.061782] devtmpfs: initialized
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.065903] NET: Registered
> protocol family 16
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.070053] geode-mfgpt: 8 MFGPT
> timers available.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.075008] geode-mfgpt:
> Registered timer 0
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.080034] mfgpt-timer:
> Registering MFGPT timer 0 as a clock event, using IRQ 7
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.090530] OLPC board with
> OpenFirmware CL1 Q2E45 Q2E
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.098100] OLPC board revision B4
> (EC=55)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.100996] PCI: Using
> configuration type OLPC
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.109230] bio: create slab
> <bio-0> at 0
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.110882] SCSI subsystem
> initialized
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.115291] Advanced Linux Sound
> Architecture Driver Version 1.0.23.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.120075] PCI: Probing PCI
> hardware
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.127804] Switching to
> clocksource tsc
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.139255] NET: Registered
> protocol family 2
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.144213] IP route cache hash
> table entries: 2048 (order: 1, 8192 bytes)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.151695] TCP established hash
> table entries: 8192 (order: 4, 65536 bytes)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.159102] TCP bind hash table
> entries: 8192 (order: 3, 32768 bytes)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.165877] TCP: Hash tables
> configured (established 8192 bind 8192)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.172310] TCP reno registered
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.175769] NET: Registered
> protocol family 1
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.180587] Trying to unpack rootfs
> image as initramfs...
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.224642] Freeing initrd memory:
> 4020k freed
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.230325] input: OLPC PM as
> /devices/virtual/input/input0
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.240838] input: OLPC lid switch
> as /devices/virtual/input/input1
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.247502] input: OLPC ebook
> switch as /devices/virtual/input/input2
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.254436] input: OLPC AC power
> jack as /devices/virtual/input/input3
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.261148] SCI is mapped to IRQ 3
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.271048] HugeTLB registered 4 MB
> page size, pre-allocated 0 pages
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.278254] JFFS2 version 2.2.
> (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.385105] PROM: Built device tree
> with 36735 bytes of memory.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.391269] msgmni has been set to
> 451
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.398593] io scheduler noop
> registered
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.402838] io scheduler cfq
> registered (default)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.407654] pci 0000:00:0f.0:
> allocated PCI BAR #1: base 0x1000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.413821] pci 0000:00:0f.0:
> cs5535-gpio: GPIO support successfully loaded.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.427606] lxfb 0000:00:01.1:
> 16384 KB of video memory at 0xfd000000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.562380] Console: switching to
> colour frame buffer device 100x40
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.608389] fb0: Geode LX frame
> buffer device
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.614263] Non-volatile memory
> driver v1.3
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.619090] AMD Geode RNG detected
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.623065] Serial: 8250/16550
> driver, 1 ports, IRQ sharing enabled
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.916824] serial8250: ttyS0 at
> I/O 0x3f8 (irq = 4) is a NS16550A
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.930412] brd: module loaded
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.933990] pci 0000:00:0f.0:
> allocated PCI BAR #2: base 0x1800
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.940832] pci 0000:00:0f.0:
> cs5535-mfgpt: 7 MFGPT timers available
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.950671] NAND device:
> Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.963360] 2 NAND chips detected
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.969418] cmdlinepart partition
> parsing not available
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.975500] Searching for RedBoot
> partition table in NAND 512MiB 3,3V 8-bit at offset 0x0
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 0.991481] No RedBoot partition
> table detected in NAND 512MiB 3,3V 8-bit
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.017369] serio: i8042 KBD port
> at 0x60,0x64 irq 1
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.023086] serio: i8042 AUX port
> at 0x60,0x64 irq 12
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.039336] rtc_cmos rtc_cmos: rtc
> core: registered rtc_cmos as rtc0
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.056715] rtc0: alarms up to one
> year, y3k, 242 bytes nvram
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.075113] olpc-dcon: Discovered
> DCON version 2
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.094945] Linux video capture
> interface: v2.00
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.204833] cpuidle: using governor
> ladder
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.221547] cpuidle: using governor
> menu
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.238261] sdhci: Secure Digital
> Host Controller Interface driver
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.258072] sdhci: Copyright(c)
> Pierre Ossman
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.276374] sdhci-pci 0000:00:0c.1:
> SDHCI controller found [11ab:4101] (rev 10)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.298621] sdhci-pci 0000:00:0c.1:
> Invalid iomem size. You may experience problems.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.322200] mmc0: SDHCI controller
> on PCI [0000:00:0c.1] using DMA
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.353854] geode-aes: GEODE AES
> engine enabled.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.376062] pci 0000:00:0f.0:
> registered timer 1
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.397663] cs5535-clockevt: Unable
> to set up the interrupt.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.420972] cs5535-clockevt: Unable
> to set up the MFGPT clock source
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.449707] Failure reading codec
> reg 0x7e,Last value=0x7e805368
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.474436] Failure reading codec
> reg 0x7e,Last value=0x7e805368
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.506668] ALSA device list:
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.528479] #0: CS5535 Audio
> cs5535audio at 0x1480, irq 5
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.554231] TCP bic registered
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.576507] Initializing XFRM
> netlink socket
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.600118] NET: Registered
> protocol family 10
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.624297] lo: Disabled Privacy
> Extensions
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.647896] Mobile IPv6
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.669158] NET: Registered
> protocol family 17
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.727104] input: AT Translated
> Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.831995] Freeing unused kernel
> memory: 240k freed
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 1.930413] udev[52]: starting
> version 161
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 7.890087] JFFS2 notice: (126)
> jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum
> (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 7.979968] dracut: Mounted root
> filesystem mtd0
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 8.743653] dcon_freeze_store: 0
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 8.746916] dcon_source_switch to
> CPU
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 8.790427] olpc-dcon: The CPU has
> control
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 8.820227] dracut: Switching root
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 9.860198] usbcore: registered new
> interface driver usbfs
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 9.867361] usbcore: registered new
> interface driver hub
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 9.872845] usbcore: registered new
> device driver usb
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 10.606582] udev[169]: starting
> version 161
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 11.130752] Marvell M88ALP01 'CAFE'
> Camera Controller version 2
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 11.151279] ohci_hcd: USB 1.1
> 'Open' Host Controller (OHCI) Driver
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 11.246808] cafe1000-ccic
> 0000:00:0c.2: enabling device (0000 -> 0002)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 11.328925] ehci_hcd: USB 2.0
> 'Enhanced' Host Controller (EHCI) Driver
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 11.658089] Warning! ehci_hcd
> should always be loaded before uhci_hcd and ohci_hcd, not after
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.275128] psmouse serio1: OLPC
> touchpad revision 0x3c
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.639344] ov7670 1-0042: chip
> found @ 0x84 (cafe_ccic)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.694021] ohci_hcd 0000:00:0f.4:
> OHCI Host Controller
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.699341] ohci_hcd 0000:00:0f.4:
> new USB bus registered, assigned bus number 1
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.730181] ohci_hcd 0000:00:0f.4:
> irq 10, io mem 0xfe01a000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.822838] input: OLPC HGPK ALPS
> HGPK as /devices/platform/i8042/serio1/input/input5
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.946693] hub 1-0:1.0: USB hub
> found
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.950483] hub 1-0:1.0: 4 ports
> detected
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 12.957744] mice: PS/2 mouse device
> common for all mice
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.007874] ehci_hcd 0000:00:0f.5:
> EHCI Host Controller
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.031931] ehci_hcd 0000:00:0f.5:
> new USB bus registered, assigned bus number 2
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.096782] ehci_hcd 0000:00:0f.5:
> irq 10, io mem 0xfe01b000
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.110642] ehci_hcd 0000:00:0f.5:
> USB 2.0 started, EHCI 1.00
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.158797] hub 2-0:1.0: USB hub
> found
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.184539] hub 2-0:1.0: 4 ports
> detected
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.510975] usb 2-1: new high speed
> USB device using ehci_hcd and address 2
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 13.794786] lib80211: common
> routines for IEEE802.11 drivers
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 14.306633] cfg80211: Calling CRDA
> to update world regulatory domain
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.235815] cfg80211: World
> regulatory domain updated:
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.265756] (start_freq -
> end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.281348] (2402000 KHz -
> 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.288465] (2457000 KHz -
> 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.320133] (2474000 KHz -
> 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.335105] (5170000 KHz -
> 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.356386] (5735000 KHz -
> 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.830108] usb8xxx: Firmware ready
> event received
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.854260] libertas:
> 00:17:c4:05:2a:1f, fw 5.110.22p23, cap 0x000003a3
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.885590] libertas: wlan0:
> Marvell WLAN 802.11 adapter
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.924370] libertas: CMD_RESP:
> error 0x0002 in command reply 0x8074
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.930862] libertas: PREP_CMD:
> command 0x0074 failed: 2
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.936185] usb8xxx: Firmware does
> not seem to support PS mode
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 15.984129] libertas: CMD_RESP:
> error 0x0001 in command reply 0x8043
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 16.007880] libertas: PREP_CMD:
> command 0x0043 failed: 1
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 16.013210] libertas:
> HOST_SLEEP_CFG failed 1
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 16.034003] usbcore: registered new
> interface driver usb8xxx
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 16.531496] udev[173]: renamed
> network interface wlan0 to eth0
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 20.489942] init:
> ck-log-system-start main process (524) terminated with status 1
> Apr 29 02:43:59 xo-05-2a-1f kernel: [ 20.970486] libertas: PREP_CMD:
> unknown command 0x004e
> Apr 29 02:44:00 xo-05-2a-1f NetworkManager[620]: <info> NetworkManager
> (version 0.8.5.92-1.git20110927.fc14) is starting...
> Apr 29 02:44:00 xo-05-2a-1f NetworkManager[620]: <info> Read config file
> /etc/NetworkManager/NetworkManager.conf
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Found user 'avahi' (UID 70)
> and group 'avahi' (GID 70).
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Successfully dropped root
> privileges.
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: avahi-daemon 0.6.27
> starting up.
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: WARNING: No NSS support for
> mDNS detected, consider installing nss-mdns!
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Successfully called
> chroot().
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Successfully dropped
> remaining capabilities.
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Loading service file
> /services/ssh.service.
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Loading service file
> /services/udisks.service.
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Network interface
> enumeration completed.
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Registering HINFO record
> with values 'I586'/'LINUX'.
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Server startup complete.
> Host name is xo-05-2a-1f.local. Local service cookie is 535333239.
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Service "xo-05-2a-1f"
> (/services/udisks.service) successfully established.
> Apr 29 02:44:00 xo-05-2a-1f avahi-daemon[633]: Service "xo-05-2a-1f"
> (/services/ssh.service) successfully established.
> Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: <info> trying to start
> the modem manager...
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> ModemManager
> (version 0.4.998-1.git20110706.fc14) starting...
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Novatel
> Apr 29 02:44:01 xo-05-2a-1f polkitd[652]: started daemon version 0.98
> using authority implementation `local' version `0.98'
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin Gobi
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin MotoC
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Samsung
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Linktop
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Longcheer
> Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: <info> monitoring kernel
> firmware directory '/lib/firmware'.
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> SimTech
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin Nokia
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Option
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Sierra
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> AnyData
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Generic
> Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: ifcfg-rh: Acquired
> D-Bus service com.redhat.ifcfgrh1
> Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: <info> Loaded plugin
> ifcfg-rh: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the
> NetworkManager mailing list.
> Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: ifcfg-rh: parsing
> /etc/sysconfig/network-scripts/ifcfg-lo ...
> Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: <info> found WiFi radio
> killswitch rfkill0 (at /sys/devices/platform/olpc-rfkill.0/rfkill/rfkill0)
> (driver olpc-rfkill)
> Apr 29 02:44:01 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Option High-Speed
> Apr 29 02:44:01 xo-05-2a-1f NetworkManager[620]: <info> found WiFi radio
> killswitch rfkill1 (at /sys/devices/virtual/ieee80211/phy0/rfkill1) (driver
> <unknown>)
> Apr 29 02:44:02 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Ericsson MBM
> Apr 29 02:44:02 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Huawei
> Apr 29 02:44:02 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin ZTE
> Apr 29 02:44:02 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin X22X
> Apr 29 02:44:02 xo-05-2a-1f modem-manager[644]: <info> Loaded plugin
> Wavecom
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> WiFi enabled by
> radio killswitch; enabled by state file
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> WWAN enabled by
> radio killswitch; enabled by state file
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> WiMAX enabled by
> radio killswitch; enabled by state file
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> Networking is
> enabled by state file
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <error>
> [1335678242.357653] [nm-device-wifi.c:3142]
> real_update_permanent_hw_address(): (eth0): unable to read permanent MAC
> address (error 0)
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): driver
> supports SSID scans (scan_capa 0x01).
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): new 802.11
> WiFi device (driver: 'usb' ifindex: 2)
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): exported
> as /org/freedesktop/NetworkManager/Devices/0
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): now managed
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 1 -> 2 (reason 2)
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): bringing
> up device.
> Apr 29 02:44:02 xo-05-2a-1f kernel: [ 26.368472] ADDRCONF(NETDEV_UP):
> eth0: link is not ready
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0): preparing
> device.
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> (eth0):
> deactivating device (reason: 2).
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]:
> supplicant_interface_acquire: assertion `mgr_state ==
> NM_SUPPLICANT_MANAGER_STATE_IDLE' failed
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> modem-manager is
> now available
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <warn> bluez error
> getting default adapter: The name org.bluez was not provided by any
> .service files
> Apr 29 02:44:02 xo-05-2a-1f NetworkManager[620]: <info> Trying to start
> the supplicant...
> Apr 29 02:44:02 xo-05-2a-1f kernel: [ 26.831857] dcon_freeze_store: 1
> Apr 29 02:44:02 xo-05-2a-1f kernel: [ 26.835120] dcon_source_switch to
> DCON
> Apr 29 02:44:02 xo-05-2a-1f kernel: [ 26.862356] olpc-dcon: The DCON
> has control
> Apr 29 02:44:03 xo-05-2a-1f olpc-switchd: starting version 47
> Apr 29 02:44:03 xo-05-2a-1f olpc-switchd: will poll power sources every 10
> seconds
> Apr 29 02:44:03 xo-05-2a-1f olpc-switchd: found 4 switches
> Apr 29 02:44:03 xo-05-2a-1f olpc-kbdshim-udev[699]: starting
> olpc-kbdshim-udev version 25
> Apr 29 02:44:04 xo-05-2a-1f olpc-kbdshim-udev[699]: fd 5: found keyboard
> (AT Translated Set 2 keyboard) /dev/input/event4 (11:01:01)
> Apr 29 02:44:04 xo-05-2a-1f olpc-kbdshim-udev[699]: fd 6: found touchpad
> (OLPC HGPK ALPS HGPK) /dev/input/event5 (11:02:0d)
> Apr 29 02:44:04 xo-05-2a-1f olpc-kbdshim-udev[699]: fd 7: found ebook
> switch
> Apr 29 02:44:04 xo-05-2a-1f powerd: powerd version 47 startup at Sun Apr
> 29 02:44:04 UYT 2012, on XO-1
> Apr 29 02:44:04 xo-05-2a-1f powerd: Linux version
> 2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9 (***@sinistra.laptop.org) (gcc
> version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 PREEMPT Wed Oct 5
> 14:05:52 EDT 2011
> Apr 29 02:44:04 xo-05-2a-1f powerd: olpc build: 20 Version a (Dextrose 3
> Uy)
> Apr 29 02:44:05 xo-05-2a-1f powerd: starting
> Apr 29 02:44:05 xo-05-2a-1f powerd: configuring from
> /etc/powerd/powerd.conf
> Apr 29 02:44:05 xo-05-2a-1f kernel: [ 29.616610] input: olpc-kbdshim
> virtual input as /devices/virtual/input/input6
> Apr 29 02:44:05 xo-05-2a-1f powerd: configured to never shutdown while
> plugged in
> Apr 29 02:44:05 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
> manager state: down -> idle
> Apr 29 02:44:05 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 2 -> 3 (reason 0)
> Apr 29 02:44:07 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
> interface state: starting -> ready
> Apr 29 02:44:08 xo-05-2a-1f kernel: [ 32.020282] ip_tables: (C)
> 2000-2006 Netfilter Core Team
> Apr 29 02:44:11 xo-05-2a-1f olpc-kbdshim-udev[699]: idle timers changed to
> 10 180 420
> Apr 29 02:44:11 xo-05-2a-1f powerd: sleep 15, dim 180, blank 420, shutdown
> after 14400
> Apr 29 02:44:34 xo-05-2a-1f gnome-keyring-daemon[1030]: GLib-GIO: Using
> the 'memory' GSettings backend. Your settings will not be saved or shared
> with other applications.
> Apr 29 02:44:34 xo-05-2a-1f gnome-keyring-daemon[1030]: couldn't set
> environment variable in session: The name org.gnome.SessionManager was not
> provided by any .service files
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> starting connection 'Auto 001a4d2f872c'
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 3 -> 4 (reason 0)
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 1 of 5 (Device Prepare) scheduled...
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 1 of 5 (Device Prepare) started...
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 2 of 5 (Device Configure) scheduled...
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 1 of 5 (Device Prepare) complete.
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 2 of 5 (Device Configure) starting...
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 4 -> 5 (reason 0)
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation
> (eth0/wireless): access point 'Auto 001a4d2f872c' has security, but secrets
> are required.
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 5 -> 6 (reason 0)
> Apr 29 02:44:36 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 2 of 5 (Device Configure) complete.
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 1 of 5 (Device Prepare) scheduled...
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 1 of 5 (Device Prepare) started...
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 6 -> 4 (reason 0)
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 2 of 5 (Device Configure) scheduled...
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 1 of 5 (Device Prepare) complete.
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 2 of 5 (Device Configure) starting...
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 4 -> 5 (reason 0)
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation
> (eth0/wireless): connection 'Auto 001a4d2f872c' has security, and secrets
> exist. No new secrets needed.
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
> 'ssid' value '001a4d2f872c'
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
> 'scan_ssid' value '1'
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
> 'key_mgmt' value 'NONE'
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
> 'auth_alg' value 'OPEN'
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
> 'wep_key0' value '<omitted>'
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: added
> 'wep_tx_keyidx' value '0'
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 2 of 5 (Device Configure) complete.
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Config: set
> interface ap_scan to 1
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
> connection state: inactive -> associating
> Apr 29 02:44:37 xo-05-2a-1f kernel: [ 61.900024]
> ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
> connection state: associating -> associated
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
> connection state: associated -> completed
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation
> (eth0/wireless) Stage 2 of 5 (Device Configure) successful. Connected to
> wireless network '001a4d2f872c'.
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 3 of 5 (IP Configure Start) scheduled.
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 3 of 5 (IP Configure Start) started...
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 5 -> 7 (reason 0)
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Beginning DHCPv4 transaction (timeout in 45 seconds)
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> dhclient started
> with pid 1043
> Apr 29 02:44:37 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 3 of 5 (IP Configure Start) complete.
> Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: Internet Systems Consortium
> DHCP Client 4.2.0-P2
> Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: Copyright 2004-2010 Internet
> Systems Consortium.
> Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: All rights reserved.
> Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: For info, please visit
> https://www.isc.org/software/dhcp/
> Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]:
> Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: Listening on
> LPF/eth0/00:17:c4:05:2a:1f
> Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: Sending on
> LPF/eth0/00:17:c4:05:2a:1f
> Apr 29 02:44:38 xo-05-2a-1f dhclient[1043]: Sending on Socket/fallback
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> (eth0): DHCPv4
> state changed nbi -> preinit
> Apr 29 02:44:39 xo-05-2a-1f dhclient[1043]: DHCPDISCOVER on eth0 to
> 255.255.255.255 port 67 interval 3
> Apr 29 02:44:39 xo-05-2a-1f dhclient[1043]: DHCPOFFER from 192.168.1.1
> Apr 29 02:44:39 xo-05-2a-1f dhclient[1043]: DHCPREQUEST on eth0 to
> 255.255.255.255 port 67
> Apr 29 02:44:39 xo-05-2a-1f dhclient[1043]: DHCPACK from 192.168.1.1
> Apr 29 02:44:39 xo-05-2a-1f dhclient[1043]: bound to 192.168.1.3 --
> renewal in 42912 seconds.
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> (eth0): DHCPv4
> state changed preinit -> bound
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 4 of 5 (IP4 Configure Get) scheduled...
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 4 of 5 (IP4 Configure Get) started...
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> address
> 192.168.1.3
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> prefix 24
> (255.255.255.0)
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> gateway
> 192.168.1.1
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> hostname
> 'dhcppc1'
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> nameserver
> '203.94.243.70'
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> nameserver
> '203.94.227.70'
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Scheduling stage 5
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 5 of 5 (IP Configure Commit) scheduled...
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Done scheduling
> stage 5
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 4 of 5 (IP4 Configure Get) complete.
> Apr 29 02:44:39 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 5 of 5 (IP Configure Commit) started...
> Apr 29 02:44:39 xo-05-2a-1f avahi-daemon[633]: Joining mDNS multicast
> group on interface eth0.IPv4 with address 192.168.1.3.
> Apr 29 02:44:39 xo-05-2a-1f avahi-daemon[633]: New relevant interface
> eth0.IPv4 for mDNS.
> Apr 29 02:44:39 xo-05-2a-1f avahi-daemon[633]: Registering new address
> record for 192.168.1.3 on eth0.IPv4.
> Apr 29 02:44:39 xo-05-2a-1f kernel: [ 63.333513] dcon_freeze_store: 0
> Apr 29 02:44:39 xo-05-2a-1f kernel: [ 63.336778] dcon_source_switch to
> CPU
> Apr 29 02:44:39 xo-05-2a-1f kernel: [ 63.370802] olpc-dcon: The CPU has
> control
> Apr 29 02:44:39 xo-05-2a-1f avahi-daemon[633]: Registering new address
> record for fe80::217:c4ff:fe05:2a1f on eth0.*.
> Apr 29 02:44:40 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 7 -> 8 (reason 0)
> Apr 29 02:44:40 xo-05-2a-1f NetworkManager[620]: <info> Policy set 'Auto
> 001a4d2f872c' (eth0) as default for IPv4 routing and DNS.
> Apr 29 02:44:40 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> successful, device activated.
> Apr 29 02:44:40 xo-05-2a-1f NetworkManager[620]: <info> Activation (eth0)
> Stage 5 of 5 (IP Configure Commit) complete.
> Apr 29 02:52:45 xo-05-2a-1f kernel: [ 549.409614] dcon_freeze_store: 1
> Apr 29 02:52:45 xo-05-2a-1f kernel: [ 549.462391] dcon_source_switch to
> DCON
> Apr 29 02:52:45 xo-05-2a-1f kernel: [ 549.502797] olpc-dcon: The DCON has
> control
> Apr 29 02:52:45 xo-05-2a-1f kernel: [ 549.649543] dcon_freeze_store: 1
> Apr 29 02:52:46 xo-05-2a-1f kernel: [ 550.060415] dcon_freeze_store: 0
> Apr 29 02:52:46 xo-05-2a-1f kernel: [ 550.060415] dcon_source_switch to
> CPU
> Apr 29 02:52:46 xo-05-2a-1f kernel: [ 550.110218] olpc-dcon: The CPU has
> control
> Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> WiFi now disabled
> by radio killswitch
> Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 8 -> 2 (reason 0)
> Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0):
> deactivating device (reason: 0).
> Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0): canceled
> DHCP transaction, DHCP client pid 1043
> Apr 29 02:52:52 xo-05-2a-1f kernel: [ 556.600861] usb 2-1: USB
> disconnect, address 2
> Apr 29 02:52:52 xo-05-2a-1f avahi-daemon[633]: Withdrawing address record
> for 192.168.1.3 on eth0.
> Apr 29 02:52:52 xo-05-2a-1f avahi-daemon[633]: Leaving mDNS multicast
> group on interface eth0.IPv4 with address 192.168.1.3.
> Apr 29 02:52:52 xo-05-2a-1f avahi-daemon[633]: Interface eth0.IPv4 no
> longer relevant for mDNS.
> Apr 29 02:52:52 xo-05-2a-1f avahi-daemon[633]: Withdrawing address record
> for fe80::217:c4ff:fe05:2a1f on eth0.
> Apr 29 02:52:52 xo-05-2a-1f avahi-daemon[633]: Withdrawing workstation
> service for eth0.
> Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0): now
> unmanaged
> Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 2 -> 1 (reason 36)
> Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> (eth0): cleaning
> up...
> Apr 29 02:52:52 xo-05-2a-1f NetworkManager[620]: <info> radio killswitch
> /sys/devices/virtual/ieee80211/phy0/rfkill1 disappeared
> Apr 29 02:52:53 xo-05-2a-1f nm-dispatcher.action: Error in get_property:
> Method "Get" with signature "ss" on interface
> "org.freedesktop.DBus.Properties" doesn't exist#012
> Apr 29 02:52:53 xo-05-2a-1f kernel: [ 557.790406] PM: Syncing filesystems
> ... done.
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.798137] Freezing user space
> processes ... (elapsed 0.02 seconds) done.
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.826215] Freezing remaining
> freezable tasks ... (elapsed 0.02 seconds) done.
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.859465] dcon_source_switch to
> DCON
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.892288] olpc-dcon: The DCON has
> control
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.916879] sdhci_pci_probe: Enable
> PME set to 0x1a0c108
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.922242] PM: suspend of devices
> complete after 62.966 msecs
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.946662] ehci_hcd 0000:00:0f.5:
> Refused to change power state, currently in D0
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.976933] ohci_hcd 0000:00:0f.4:
> Refused to change power state, currently in D0
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.984608] PM: late suspend of
> devices complete after 56.429 msecs
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.993192] olpc_do_sleep!
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 557.993192] PM: early resume of
> devices complete after 0.521 msecs
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.111968] usb usb1: root hub lost
> power or was reset
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.133970] usb usb2: root hub lost
> power or was reset
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.145371] dcon_source_switch to
> CPU
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.187020] olpc-dcon: The CPU has
> control
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.416732] PM: resume of devices
> complete after 411.146 msecs
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.422745] Restarting tasks ...
> done.
> Apr 29 03:11:25 xo-05-2a-1f NetworkManager[620]: <info> WiFi now enabled
> by radio killswitch
> Apr 29 03:11:25 xo-05-2a-1f kernel: [ 558.934219] dcon_freeze_store: 0
> Apr 29 03:11:26 xo-05-2a-1f kernel: [ 558.996489] dcon_freeze_store: 0
> Apr 29 03:11:26 xo-05-2a-1f kernel: [ 559.176729] usb 2-1: new high speed
> USB device using ehci_hcd and address 3
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.065633] usb8xxx: Firmware ready
> event received
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.092068] libertas:
> 00:17:c4:05:2a:1f, fw 5.110.22p23, cap 0x000003a3
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.111778] libertas: wlan0:
> Marvell WLAN 802.11 adapter
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.138293] libertas: CMD_RESP:
> error 0x0002 in command reply 0x8074
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.144914] libertas: PREP_CMD:
> command 0x0074 failed: 2
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.150243] usb8xxx: Firmware does
> not seem to support PS mode
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.208672] libertas: CMD_RESP:
> error 0x0001 in command reply 0x8043
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.215439] libertas: PREP_CMD:
> command 0x0043 failed: 1
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.220769] libertas:
> HOST_SLEEP_CFG failed 1
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> found WiFi radio
> killswitch rfkill2 (at /sys/devices/virtual/ieee80211/phy1/rfkill2) (driver
> <unknown>)
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.563949] udev[1400]: renamed
> network interface wlan0 to eth0
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): new 802.11
> OLPC Mesh device (driver: 'usb' ifindex: 5)
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): exported
> as /org/freedesktop/NetworkManager/Devices/1
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): now managed
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): device
> state change: 1 -> 2 (reason 2)
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): bringing
> up device.
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): preparing
> device.
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0):
> deactivating device (reason: 2).
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <error>
> [1335679887.687698] [nm-device-wifi.c:3142]
> real_update_permanent_hw_address(): (eth0): unable to read permanent MAC
> address (error 0)
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): driver
> supports SSID scans (scan_capa 0x01).
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): new 802.11
> WiFi device (driver: 'usb' ifindex: 4)
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): exported
> as /org/freedesktop/NetworkManager/Devices/2
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): now managed
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 1 -> 2 (reason 2)
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): bringing
> up device.
> Apr 29 03:11:27 xo-05-2a-1f kernel: [ 560.738668] ADDRCONF(NETDEV_UP):
> eth0: link is not ready
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0): preparing
> device.
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (eth0):
> deactivating device (reason: 2).
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): device
> state change: 2 -> 3 (reason 0)
> Apr 29 03:11:27 xo-05-2a-1f NetworkManager[620]: <info> (msh0): found
> companion WiFi device eth0
> Apr 29 03:11:28 xo-05-2a-1f NetworkManager[620]: <info> (eth0): supplicant
> interface state: starting -> ready
> Apr 29 03:11:28 xo-05-2a-1f NetworkManager[620]: <info> (eth0): device
> state change: 2 -> 3 (reason 42)
> Apr 29 03:11:28 xo-05-2a-1f avahi-daemon[633]: Withdrawing workstation
> service for msh0.
> Apr 29 03:11:28 xo-05-2a-1f NetworkManager[620]: <info> (msh0): now
> unmanaged
> Apr 29 03:11:28 xo-05-2a-1f NetworkManager[620]: <info> (msh0): device
> state change: 3 -> 1 (reason 36)
> Apr 29 03:11:28 xo-05-2a-1f NetworkManager[620]: <info> (msh0): cleaning
> up...
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: <warn> caught signal 11.
> Generating backtrace...
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: ******************* START
> **********************************
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 0: NetworkManager
> (nm_logging_backtrace+0x56) [0x80a1536]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 1: NetworkManager
> (0x8048000+0x8085ee5) [0x8085ee5]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 2: (vdso)
> (__kernel_sigreturn+0x0) [0xb778b400]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 3: NetworkManager
> (0x8048000+0x8076404) [0x8076404]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 4:
> /lib/libgobject-2.0.so.0 (g_cclosure_marshal_VOID__PARAM+0x88) [0xb72c5588]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 5:
> /lib/libgobject-2.0.so.0 (g_closure_invoke+0x193) [0xb72a8be3]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 6:
> /lib/libgobject-2.0.so.0 (0xb729d000+0xb72bb0f0) [0xb72bb0f0]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 7:
> /lib/libgobject-2.0.so.0 (g_signal_emit_valist+0x80e) [0xb72c424e]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 8:
> /lib/libgobject-2.0.so.0 (g_signal_emit+0x33) [0xb72c4403]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 9:
> /lib/libgobject-2.0.so.0 (0xb729d000+0xb72aa891) [0xb72aa891]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 10:
> /lib/libgobject-2.0.so.0 (0xb729d000+0xb72a9c70) [0xb72a9c70]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 11:
> /lib/libgobject-2.0.so.0 (g_object_notify+0x551) [0xb72acbe1]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 12:
> /lib/libgobject-2.0.so.0 (g_cclosure_marshal_VOID__PARAM+0x88) [0xb72c5588]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 13:
> /lib/libgobject-2.0.so.0 (g_closure_invoke+0x193) [0xb72a8be3]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 14:
> /lib/libgobject-2.0.so.0 (0xb729d000+0xb72bb0f0) [0xb72bb0f0]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 15:
> /lib/libgobject-2.0.so.0 (g_signal_emit_valist+0x80e) [0xb72c424e]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 16:
> /lib/libgobject-2.0.so.0 (g_signal_emit+0x33) [0xb72c4403]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 17:
> /lib/libgobject-2.0.so.0 (0xb729d000+0xb72aa891) [0xb72aa891]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 18:
> /lib/libgobject-2.0.so.0 (0xb729d000+0xb72a9c70) [0xb72a9c70]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 19:
> /lib/libgobject-2.0.so.0 (g_object_notify+0x551) [0xb72acbe1]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 20: NetworkManager
> (0x8048000+0x80bcb6f) [0x80bcb6f]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 21:
> /lib/libgobject-2.0.so.0 (g_cclosure_marshal_VOID__BOOLEAN+0x88)
> [0xb72c4c88]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 22:
> /usr/lib/libdbus-glib-1.so.2 (0xb74e2000+0xb74f010c) [0xb74f010c]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 23:
> /lib/libgobject-2.0.so.0 (g_closure_invoke+0x193) [0xb72a8be3]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 24:
> /lib/libgobject-2.0.so.0 (0xb729d000+0xb72bb0f0) [0xb72bb0f0]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 25:
> /lib/libgobject-2.0.so.0 (g_signal_emit_valist+0x80e) [0xb72c424e]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 26:
> /lib/libgobject-2.0.so.0 (g_signal_emit+0x33) [0xb72c4403]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 27:
> /usr/lib/libdbus-glib-1.so.2 (0xb74e2000+0xb74f0d35) [0xb74f0d35]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 28:
> /lib/libdbus-1.so.3 (dbus_connection_dispatch+0x393) [0xb74a4f03]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 29:
> /usr/lib/libdbus-glib-1.so.2 (0xb74e2000+0xb74e920e) [0xb74e920e]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 30:
> /lib/libglib-2.0.so.0 (g_main_context_dispatch+0x1d2) [0xb71bd192]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 31:
> /lib/libglib-2.0.so.0 (0xb717d000+0xb71bd978) [0xb71bd978]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 32:
> /lib/libglib-2.0.so.0 (g_main_loop_run+0x18b) [0xb71be04b]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 33: NetworkManager
> (main+0x15d6) [0x80876b6]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 34: /lib/libc.so.6
> (__libc_start_main+0xe6) [0xb6fd9e36]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: Frame 35: NetworkManager
> (0x8048000+0x805df01) [0x805df01]
> Apr 29 03:11:29 xo-05-2a-1f NetworkManager[620]: ******************* END
> **********************************
> Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.307009] usb 2-2: new high speed
> USB device using ehci_hcd and address 4
> Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.521615] usbcore: registered new
> interface driver libusual
> Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.610166] Initializing USB Mass
> Storage driver...
> Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.619576] scsi0 : usb-storage
> 2-2:1.0
> Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.630555] usbcore: registered new
> interface driver usb-storage
> Apr 29 04:20:51 xo-05-2a-1f kernel: [ 4724.636943] USB Mass Storage
> support registered.
> Apr 29 04:20:52 xo-05-2a-1f kernel: [ 4725.663079] scsi 0:0:0:0:
> Direct-Access Kingston DataTraveler 108 PMAP PQ: 0 ANSI: 0 CCS
> Apr 29 04:20:52 xo-05-2a-1f kernel: [ 4725.726899] sd 0:0:0:0: Attached
> scsi generic sg0 type 0
> Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.416348] sd 0:0:0:0: [sda]
> 15646720 512-byte logical blocks: (8.01 GB/7.46 GiB)
> Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.426369] sd 0:0:0:0: [sda] Write
> Protect is off
> Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.431204] sd 0:0:0:0: [sda]
> Assuming drive cache: write through
> Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.444165] sd 0:0:0:0: [sda]
> Assuming drive cache: write through
> Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.450419] sda: sda1
> Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.473921] sd 0:0:0:0: [sda]
> Assuming drive cache: write through
> Apr 29 04:20:53 xo-05-2a-1f kernel: [ 4726.480282] sd 0:0:0:0: [sda]
> Attached SCSI removable disk
>
> ####################################################################################################################
>
>
> Looking forward to some guiding light.
>
>
> Regards,
> Ajay
>
>
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
Jon Nettleton
2012-04-29 09:34:42 UTC
Permalink
On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
<***@gmail.com> wrote:
> Are you guys still using this?
> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/postresume.d/disable_mesh.sh
>
> If so, you should remove it IF there is no way to guarantee that it will run
> before NM picks up the device. At least it will avoid the crash...
>
> I would ask in the NM community if there is a better way to disable a
> particular device, like banning a device(?).

Edit /etc/NetworkManager/NetworkManager.conf

Add a line to the [main] section like

no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
mac-address of your mesh device.)

This does not stop NM from managing your device, but does stop it from
auto-connecting the device. You would still be able to go into NM and
manually enable the mesh network. If you want NM to completely leave
the device alone you can go one more step.

Also in /etc/NetworkManager/NetworkManager.conf

change the plugins line to

plugins=ifcfg-rh,keyfile

Then add a section that looks like this.

[keyfile]
unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address
of the device you want to ignore)


Hope that helps, let me know if you have further questions.

-Jon
Jon Nettleton
2012-04-29 09:36:14 UTC
Permalink
One thing I forgot to add. You can use the standard udi format to
specify devices. i.e /org/freedesktop/NetworkManager/Devices/0

On Sun, Apr 29, 2012 at 11:34 AM, Jon Nettleton <***@gmail.com> wrote:
> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
> <***@gmail.com> wrote:
>> Are you guys still using this?
>> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/postresume.d/disable_mesh.sh
>>
>> If so, you should remove it IF there is no way to guarantee that it will run
>> before NM picks up the device. At least it will avoid the crash...
>>
>> I would ask in the NM community if there is a better way to disable a
>> particular device, like banning a device(?).
>
> Edit /etc/NetworkManager/NetworkManager.conf
>
> Add a line to the [main] section like
>
> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
> mac-address of your mesh device.)
>
> This does not stop NM from managing your device, but does stop it from
> auto-connecting the device.  You would still be able to go into NM and
> manually enable the mesh network.   If you want NM to completely leave
> the device alone you can go one more step.
>
> Also in /etc/NetworkManager/NetworkManager.conf
>
> change the plugins line to
>
> plugins=ifcfg-rh,keyfile
>
> Then add a section that looks like this.
>
> [keyfile]
> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address
> of the device you want to ignore)
>
>
> Hope that helps, let me know if you have further questions.
>
> -Jon
Ajay Garg
2012-04-30 07:30:15 UTC
Permalink
Thanks Martin and Jon for the replies.

On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <***@gmail.com>wrote:

> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
> <***@gmail.com> wrote:
> > Are you guys still using this?
> >
> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/postresume.d/disable_mesh.sh
> >
> > If so, you should remove it IF there is no way to guarantee that it will
> run
> > before NM picks up the device. At least it will avoid the crash...
> >
> > I would ask in the NM community if there is a better way to disable a
> > particular device, like banning a device(?).
>
> Edit /etc/NetworkManager/NetworkManager.conf
>
> Add a line to the [main] section like
>
> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
> mac-address of your mesh device.)
>


This should be a lot cleaner solution.
However, two queries ::


a)
Doing "ifconfig" on the XO-1, only shows information for "eth0" and "lo"
(no mesh device listed).
So, how can the mac address for the mesh device be found?


b)
Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet?


Looking forward to a reply.



Thanks and Regards,
Ajay



>
> This does not stop NM from managing your device, but does stop it from
> auto-connecting the device. You would still be able to go into NM and
> manually enable the mesh network. If you want NM to completely leave
> the device alone you can go one more step.
>
> Also in /etc/NetworkManager/NetworkManager.conf
>
> change the plugins line to
>
> plugins=ifcfg-rh,keyfile
>
> Then add a section that looks like this.
>
> [keyfile]
> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address
> of the device you want to ignore)
>
>
> Hope that helps, let me know if you have further questions.
>
> -Jon
>
Ajay Garg
2012-05-01 13:56:27 UTC
Permalink
Any ideas please, regarding the two latest queries :) ?

Regards,
Ajay

On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg <***@activitycentral.com> wrote:

> Thanks Martin and Jon for the replies.
>
> On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <***@gmail.com>wrote:
>
>> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
>> <***@gmail.com> wrote:
>> > Are you guys still using this?
>> >
>> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/postresume.d/disable_mesh.sh
>> >
>> > If so, you should remove it IF there is no way to guarantee that it
>> will run
>> > before NM picks up the device. At least it will avoid the crash...
>> >
>> > I would ask in the NM community if there is a better way to disable a
>> > particular device, like banning a device(?).
>>
>> Edit /etc/NetworkManager/NetworkManager.conf
>>
>> Add a line to the [main] section like
>>
>> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
>> mac-address of your mesh device.)
>>
>
>
> This should be a lot cleaner solution.
> However, two queries ::
>
>
> a)
> Doing "ifconfig" on the XO-1, only shows information for "eth0" and "lo"
> (no mesh device listed).
> So, how can the mac address for the mesh device be found?
>
>
> b)
> Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet?
>
>
> Looking forward to a reply.
>
>
>
> Thanks and Regards,
> Ajay
>
>
>
>>
>> This does not stop NM from managing your device, but does stop it from
>> auto-connecting the device. You would still be able to go into NM and
>> manually enable the mesh network. If you want NM to completely leave
>> the device alone you can go one more step.
>>
>> Also in /etc/NetworkManager/NetworkManager.conf
>>
>> change the plugins line to
>>
>> plugins=ifcfg-rh,keyfile
>>
>> Then add a section that looks like this.
>>
>> [keyfile]
>> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address
>> of the device you want to ignore)
>>
>>
>> Hope that helps, let me know if you have further questions.
>>
>> -Jon
>>
>
>
Paul Fox
2012-05-01 14:33:39 UTC
Permalink
ajay wrote:
> Any ideas please, regarding the two latest queries :) ?
>
> Regards,
> Ajay
>
> On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg <***@activitycentral.com> wrote:
>
> > Thanks Martin and Jon for the replies.
> >
> > On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <***@gmail.com>wrote:
> >
> >> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
> >> <***@gmail.com> wrote:
> >> > Are you guys still using this?
> >> >
> >>
> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
> resume.d/disable_mesh.sh
> >> >
> >> > If so, you should remove it IF there is no way to guarantee that it
> >> will run
> >> > before NM picks up the device. At least it will avoid the crash...
> >> >
> >> > I would ask in the NM community if there is a better way to disable a
> >> > particular device, like banning a device(?).
> >>
> >> Edit /etc/NetworkManager/NetworkManager.conf
> >>
> >> Add a line to the [main] section like
> >>
> >> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
> >> mac-address of your mesh device.)
> >>
> >
> >
> > This should be a lot cleaner solution.
> > However, two queries ::
> >
> >
> > a)
> > Doing "ifconfig" on the XO-1, only shows information for "eth0" and "lo"
> > (no mesh device listed).
> > So, how can the mac address for the mesh device be found?

it's the same as that for eth0.

> > b)
> > Are mac address for XO-1s, EXACTLY same, for every XO-1 on this planet?

of course not. how would they tell one another apart?

paul

> >
> >
> > Looking forward to a reply.
> >
> >
> >
> > Thanks and Regards,
> > Ajay
> >
> >
> >
> >>
> >> This does not stop NM from managing your device, but does stop it from
> >> auto-connecting the device. You would still be able to go into NM and
> >> manually enable the mesh network. If you want NM to completely leave
> >> the device alone you can go one more step.
> >>
> >> Also in /etc/NetworkManager/NetworkManager.conf
> >>
> >> change the plugins line to
> >>
> >> plugins=ifcfg-rh,keyfile
> >>
> >> Then add a section that looks like this.
> >>
> >> [keyfile]
> >> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac address
> >> of the device you want to ignore)
> >>
> >>
> >> Hope that helps, let me know if you have further questions.
> >>
> >> -Jon
> >>
> >
> >
> part 2 text/plain 129
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel

=---------------------
paul fox, ***@laptop.org
Ajay Garg
2012-05-01 14:37:51 UTC
Permalink
Thanks Paul.

On Tue, May 1, 2012 at 8:03 PM, Paul Fox <***@laptop.org> wrote:

> ajay wrote:
> > Any ideas please, regarding the two latest queries :) ?
> >
> > Regards,
> > Ajay
> >
> > On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg <***@activitycentral.com>
> wrote:
> >
> > > Thanks Martin and Jon for the replies.
> > >
> > > On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <
> ***@gmail.com>wrote:
> > >
> > >> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
> > >> <***@gmail.com> wrote:
> > >> > Are you guys still using this?
> > >> >
> > >>
> >
> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
> > resume.d/disable_mesh.sh
> > >> >
> > >> > If so, you should remove it IF there is no way to guarantee that it
> > >> will run
> > >> > before NM picks up the device. At least it will avoid the crash...
> > >> >
> > >> > I would ask in the NM community if there is a better way to
> disable a
> > >> > particular device, like banning a device(?).
> > >>
> > >> Edit /etc/NetworkManager/NetworkManager.conf
> > >>
> > >> Add a line to the [main] section like
> > >>
> > >> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
> > >> mac-address of your mesh device.)
> > >>
> > >
> > >
> > > This should be a lot cleaner solution.
> > > However, two queries ::
> > >
> > >
> > > a)
> > > Doing "ifconfig" on the XO-1, only shows information for "eth0" and
> "lo"
> > > (no mesh device listed).
> > > So, how can the mac address for the mesh device be found?
>
> it's the same as that for eth0.
>

Does that mean, that banning eth0-mac-address prevent the loading of
wifi-hardware-device as well (in obvious addition to mesh) ?
This seems very pricky.





>
> > > b)
> > > Are mac address for XO-1s, EXACTLY same, for every XO-1 on this
> planet?
>
> of course not. how would they tell one another apart?
>

Alright.
But my first doubt (same mac address for mesh-hardware and wifi-hardware)
has put me in topspin :~



Regards,
Ajay





>
> paul
>
> > >
> > >
> > > Looking forward to a reply.
> > >
> > >
> > >
> > > Thanks and Regards,
> > > Ajay
> > >
> > >
> > >
> > >>
> > >> This does not stop NM from managing your device, but does stop it
> from
> > >> auto-connecting the device. You would still be able to go into NM
> and
> > >> manually enable the mesh network. If you want NM to completely
> leave
> > >> the device alone you can go one more step.
> > >>
> > >> Also in /etc/NetworkManager/NetworkManager.conf
> > >>
> > >> change the plugins line to
> > >>
> > >> plugins=ifcfg-rh,keyfile
> > >>
> > >> Then add a section that looks like this.
> > >>
> > >> [keyfile]
> > >> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac
> address
> > >> of the device you want to ignore)
> > >>
> > >>
> > >> Hope that helps, let me know if you have further questions.
> > >>
> > >> -Jon
> > >>
> > >
> > >
> > part 2 text/plain 129
> > _______________________________________________
> > Devel mailing list
> > ***@lists.laptop.org
> > http://lists.laptop.org/listinfo/devel
>
> =---------------------
> paul fox, ***@laptop.org
>
Ajay Garg
2012-05-01 14:55:46 UTC
Permalink
which actually brings me back to my original question ::

"""
Why is it so that putting the 'disable-mesh-script' in the 'start()' method
of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never
works for resume-upon-suspend?
"""


Regards,
Ajay

On Tue, May 1, 2012 at 8:07 PM, Ajay Garg <***@activitycentral.com> wrote:

> Thanks Paul.
>
> On Tue, May 1, 2012 at 8:03 PM, Paul Fox <***@laptop.org> wrote:
>
>> ajay wrote:
>> > Any ideas please, regarding the two latest queries :) ?
>> >
>> > Regards,
>> > Ajay
>> >
>> > On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg <***@activitycentral.com>
>> wrote:
>> >
>> > > Thanks Martin and Jon for the replies.
>> > >
>> > > On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <
>> ***@gmail.com>wrote:
>> > >
>> > >> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
>> > >> <***@gmail.com> wrote:
>> > >> > Are you guys still using this?
>> > >> >
>> > >>
>> >
>> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
>> > resume.d/disable_mesh.sh
>> > >> >
>> > >> > If so, you should remove it IF there is no way to guarantee that
>> it
>> > >> will run
>> > >> > before NM picks up the device. At least it will avoid the crash...
>> > >> >
>> > >> > I would ask in the NM community if there is a better way to
>> disable a
>> > >> > particular device, like banning a device(?).
>> > >>
>> > >> Edit /etc/NetworkManager/NetworkManager.conf
>> > >>
>> > >> Add a line to the [main] section like
>> > >>
>> > >> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
>> > >> mac-address of your mesh device.)
>> > >>
>> > >
>> > >
>> > > This should be a lot cleaner solution.
>> > > However, two queries ::
>> > >
>> > >
>> > > a)
>> > > Doing "ifconfig" on the XO-1, only shows information for "eth0" and
>> "lo"
>> > > (no mesh device listed).
>> > > So, how can the mac address for the mesh device be found?
>>
>> it's the same as that for eth0.
>>
>
> Does that mean, that banning eth0-mac-address prevent the loading of
> wifi-hardware-device as well (in obvious addition to mesh) ?
> This seems very pricky.
>
>
>
>
>
>>
>> > > b)
>> > > Are mac address for XO-1s, EXACTLY same, for every XO-1 on this
>> planet?
>>
>> of course not. how would they tell one another apart?
>>
>
> Alright.
> But my first doubt (same mac address for mesh-hardware and wifi-hardware)
> has put me in topspin :~
>
>
>
> Regards,
> Ajay
>
>
>
>
>
>>
>> paul
>>
>> > >
>> > >
>> > > Looking forward to a reply.
>> > >
>> > >
>> > >
>> > > Thanks and Regards,
>> > > Ajay
>> > >
>> > >
>> > >
>> > >>
>> > >> This does not stop NM from managing your device, but does stop it
>> from
>> > >> auto-connecting the device. You would still be able to go into NM
>> and
>> > >> manually enable the mesh network. If you want NM to completely
>> leave
>> > >> the device alone you can go one more step.
>> > >>
>> > >> Also in /etc/NetworkManager/NetworkManager.conf
>> > >>
>> > >> change the plugins line to
>> > >>
>> > >> plugins=ifcfg-rh,keyfile
>> > >>
>> > >> Then add a section that looks like this.
>> > >>
>> > >> [keyfile]
>> > >> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac
>> address
>> > >> of the device you want to ignore)
>> > >>
>> > >>
>> > >> Hope that helps, let me know if you have further questions.
>> > >>
>> > >> -Jon
>> > >>
>> > >
>> > >
>> > part 2 text/plain 129
>> > _______________________________________________
>> > Devel mailing list
>> > ***@lists.laptop.org
>> > http://lists.laptop.org/listinfo/devel
>>
>> =---------------------
>> paul fox, ***@laptop.org
>>
>
>
Peter Robinson
2012-05-01 16:06:18 UTC
Permalink
On Tue, May 1, 2012 at 3:55 PM, Ajay Garg <***@activitycentral.com> wrote:
> which actually brings me back to my original question ::
>
> """
> Why is it so that putting the 'disable-mesh-script' in the 'start()' method
> of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never works
> for resume-upon-suspend?
> """

Because on suspend/resume the NetworkManager service isn't
started/restarted so the script in /etc/init.d isn't run where as on
reboot it is. There's means though to run specific scripts on
suspend/resume if that sort of thing is necessary.

Peter
Ajay Garg
2012-05-02 03:40:05 UTC
Permalink
Hi all.

I'll ask this straight ::

"""
Is there an already tested-cum-recommended method, that could disable
mesh-network, both during reboots and resume-from-suspend?
"""

Possible options (not tested by me) ::


a)
A driver, encapsulating the patch at
http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html
(as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES)


Query : How can I ascertain if this patch is present on a particular XO-1?





b)
(For Reboot) ::
Add the bootstrap script 'echo 0 > "/sys/class/net/eth0/lbs_mesh"' in
'/etc/init.d/NetworkMaanager'.

(For Resume-Upon-Suspend) ::
Add the disable_mesh.sh script (at
http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm)
in "/etc/powerd/postresume.d".


Query : While the (For Reboot) case is guaranteed to work stably every
single time, can the same be said about (For Resume-Upon-Suspend) ?




c) Any other unknown in-the-dark hack.



Regards,
Ajay



On Tue, May 1, 2012 at 9:36 PM, Peter Robinson <***@gmail.com> wrote:

> On Tue, May 1, 2012 at 3:55 PM, Ajay Garg <***@activitycentral.com>
> wrote:
> > which actually brings me back to my original question ::
> >
> > """
> > Why is it so that putting the 'disable-mesh-script' in the 'start()'
> method
> > of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never
> works
> > for resume-upon-suspend?
> > """
>
> Because on suspend/resume the NetworkManager service isn't
> started/restarted so the script in /etc/init.d isn't run where as on
> reboot it is. There's means though to run specific scripts on
> suspend/resume if that sort of thing is necessary.
>
> Peter
>
Ajay Garg
2012-05-02 03:44:26 UTC
Permalink
Just an updated version ::


Hi all.

I'll ask this straight ::

"""
Is there an already tested-cum-recommended method, that could disable
mesh-network, both during reboots and resume-from-suspend?
"""

Possible options (not tested by me) ::


a)
A driver, encapsulating the patch at
http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html
(as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES)


Query : How can I ascertain if this patch is present on a particular XO-1?





b)
(For Reboot) ::
Add the bootstrap script 'echo 0 > "/sys/class/net/eth0/lbs_mesh"' in
'/etc/init.d/NetworkMaanager'.

(For Resume-Upon-Suspend) ::
Add the disable_mesh.sh script (at
http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm)
in "/etc/powerd/postresume.d".


Query : While the (For Reboot) case is guaranteed to work stably every
single time, can the same be said about (For Resume-Upon-Suspend) ?
Answer : No. The (Resume-Upon-Suspend) case does not work. So, this
solution is rejected.




c) Any other unknown in-the-dark hack.



Regards,
Ajay

On Wed, May 2, 2012 at 9:10 AM, Ajay Garg <***@activitycentral.com> wrote:

> Hi all.
>
> I'll ask this straight ::
>
> """
> Is there an already tested-cum-recommended method, that could disable
> mesh-network, both during reboots and resume-from-suspend?
> """
>
> Possible options (not tested by me) ::
>
>
> a)
> A driver, encapsulating the patch at
> http://lists.infradead.org/pipermail/libertas-dev/2007-June/000448.html
> (as per http://dev.laptop.org/pub/firmware/libertas/RELEASE_NOTES)
>
>
> Query : How can I ascertain if this patch is present on a particular XO-1?
>
>
>
>
>
> b)
> (For Reboot) ::
> Add the bootstrap script 'echo 0 > "/sys/class/net/eth0/lbs_mesh"' in
> '/etc/init.d/NetworkMaanager'.
>
> (For Resume-Upon-Suspend) ::
> Add the disable_mesh.sh script (at
> http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm)
> in "/etc/powerd/postresume.d".
>
>
> Query : While the (For Reboot) case is guaranteed to work stably every
> single time, can the same be said about (For Resume-Upon-Suspend) ?
>
>
>
>
> c) Any other unknown in-the-dark hack.
>
>
>
> Regards,
> Ajay
>
>
>
>
> On Tue, May 1, 2012 at 9:36 PM, Peter Robinson <***@gmail.com>wrote:
>
>> On Tue, May 1, 2012 at 3:55 PM, Ajay Garg <***@activitycentral.com>
>> wrote:
>> > which actually brings me back to my original question ::
>> >
>> > """
>> > Why is it so that putting the 'disable-mesh-script' in the 'start()'
>> method
>> > of '/etc/init.d/Networkmanager' works (always) for (re)boot; but never
>> works
>> > for resume-upon-suspend?
>> > """
>>
>> Because on suspend/resume the NetworkManager service isn't
>> started/restarted so the script in /etc/init.d isn't run where as on
>> reboot it is. There's means though to run specific scripts on
>> suspend/resume if that sort of thing is necessary.
>>
>> Peter
>>
>
>
James Cameron
2012-05-02 03:51:13 UTC
Permalink
On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
> Is there an already tested-cum-recommended method, that could disable
> mesh-network, both during reboots and resume-from-suspend?

Not that I know of.

But I'm curious, why do you need to do this? Is there some other
problem you think you will solve with this? There might be an alternate
solution.

--
James Cameron
http://quozl.linux.org.au/
Ajay Garg
2012-05-02 04:03:36 UTC
Permalink
Thanks James for the reply.

On Wed, May 2, 2012 at 9:21 AM, James Cameron <***@laptop.org> wrote:

> On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
> > Is there an already tested-cum-recommended method, that could disable
> > mesh-network, both during reboots and resume-from-suspend?
>
> Not that I know of.
>
> But I'm curious, why do you need to do this? Is there some other
> problem you think you will solve with this? There might be an alternate
> solution.
>

No, nothing of that sort.
Just wish to remove the mesh-icons from Neighborhood-View.

Right now, we were trying the disable-mesh-script (''echo 0 >
"/sys/class/net/eth0/lbs_mesh"") for our purpose.
Now, I am thinking of removing all references to devices of type
"DEVICE_TYPE_802_11_OLPC_MESH" from sugar-code. I think that should do it.

Thanks to all for your quick responses.

Thanks and Regards,
Ajay



>
> --
> James Cameron
> http://quozl.linux.org.au/
> _______________________________________________
> Sugar-devel mailing list
> Sugar-***@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
James Cameron
2012-05-02 04:09:50 UTC
Permalink
On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
> Thanks James for the reply.
>
> On Wed, May 2, 2012 at 9:21 AM, James Cameron <***@laptop.org> wrote:
>
> On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
> > Is there an already tested-cum-recommended method, that could disable
> > mesh-network, both during reboots and resume-from-suspend?
>
> Not that I know of.
>
> But I'm curious, why do you need to do this? Is there some other
> problem you think you will solve with this? There might be an alternate
> solution.
>
>
> No, nothing of that sort.
> Just wish to remove the mesh-icons from Neighborhood-View.

But why?

> Right now, we were trying the disable-mesh-script (''echo 0 > "/sys/class/net/
> eth0/lbs_mesh"") for our purpose.
> Now, I am thinking of removing all references to devices of type
> "DEVICE_TYPE_802_11_OLPC_MESH" from sugar-code. I think that should do it.

Yes, that should do it.

--
James Cameron
http://quozl.linux.org.au/
Ajay Garg
2012-05-02 04:13:38 UTC
Permalink
On Wed, May 2, 2012 at 9:39 AM, James Cameron <***@laptop.org> wrote:

> On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
> > Thanks James for the reply.
> >
> > On Wed, May 2, 2012 at 9:21 AM, James Cameron <***@laptop.org> wrote:
> >
> > On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
> > > Is there an already tested-cum-recommended method, that could
> disable
> > > mesh-network, both during reboots and resume-from-suspend?
> >
> > Not that I know of.
> >
> > But I'm curious, why do you need to do this? Is there some other
> > problem you think you will solve with this? There might be an
> alternate
> > solution.
> >
> >
> > No, nothing of that sort.
> > Just wish to remove the mesh-icons from Neighborhood-View.
>
> But why?
>

Just that, we do not wish to set up a mesh-network, as per say.
By removing all references to the device, we could provide a "soft"
solution :)

Thanks again.

Regards,
Ajay


>
> > Right now, we were trying the disable-mesh-script (''echo 0 >
> "/sys/class/net/
> > eth0/lbs_mesh"") for our purpose.
> > Now, I am thinking of removing all references to devices of type
> > "DEVICE_TYPE_802_11_OLPC_MESH" from sugar-code. I think that should do
> it.
>
> Yes, that should do it.
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
Martin Langhoff
2012-05-02 06:19:34 UTC
Permalink
On Wed, May 2, 2012 at 12:13 AM, Ajay Garg <***@gmail.com> wrote:
> Just that, we do not wish to set up a mesh-network, as per say.

I think you are missing the background reason here. AFAIK, reasons to
disable mesh network on XO-1:

- Mesh can easily saturate RF, so dense usage scenarios (schools!)
benefit from switching it off.

- Easier out-of-the-box interop with later XO-1.x models, where the
"under a tree" network uses ad-hoc 802.11g.

> By removing all references to the device, we could provide a "soft" solution

Nah, messing with Sugar code is the wrong solution.



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
Ajay Garg
2012-05-02 06:25:21 UTC
Permalink
On Wed, May 2, 2012 at 11:49 AM, Martin Langhoff
<***@gmail.com>wrote:

> On Wed, May 2, 2012 at 12:13 AM, Ajay Garg <***@gmail.com> wrote:
> > Just that, we do not wish to set up a mesh-network, as per say.
>
> I think you are missing the background reason here. AFAIK, reasons to
> disable mesh network on XO-1:
>
> - Mesh can easily saturate RF, so dense usage scenarios (schools!)
> benefit from switching it off.
>
> - Easier out-of-the-box interop with later XO-1.x models, where the
> "under a tree" network uses ad-hoc 802.11g.
>
> > By removing all references to the device, we could provide a "soft"
> solution
>
> Nah, messing with Sugar code is the wrong solution.
>

I agree. But there is no working lower-level solution :\


Regards,
Ajay



>
>
> 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
2012-05-02 07:02:04 UTC
Permalink
On Wed, May 2, 2012 at 2:25 AM, Ajay Garg <***@gmail.com> wrote:
> I agree. But there is no working lower-level solution :\

Let's fix that. Messing with Sugar won't help you.

Earlier in the thread someone pointed to you the scripts to trigger on
resume (by powerd). Do those work? Not work? What's the problem there?

AIUI, if you

- disable mesh on boot
- disable mesh on resume, from a powerd-triggered script
- blacklist the MAC address so NM ignores it

you win. Yes, every XO has a different MAC address, but you can read
that on first boot of the OS, and write the NM configuration. See the
olpc-configure script for examples.

cheers,



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
Ajay Garg
2012-05-02 07:22:03 UTC
Permalink
Thanks Martin (a ton !!)

On Wed, May 2, 2012 at 12:32 PM, Martin Langhoff
<***@gmail.com>wrote:

> On Wed, May 2, 2012 at 2:25 AM, Ajay Garg <***@gmail.com> wrote:
> > I agree. But there is no working lower-level solution :\
>
> Let's fix that.


Great !!!







> Messing with Sugar won't help you.
>
> Earlier in the thread someone pointed to you the scripts to trigger on
> resume (by powerd). Do those work? Not work? What's the problem there?
>

The /etc/powerd/postresume.d/disable_mesh.sh doesn't work.
My belief is that there is the same problem - race condition between the
'echo 0' script, and NetworkManager. This causes the NetworkManager to
crash randomly.






>
> AIUI, if you
>
> - disable mesh on boot
>

Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so
that the effect takes place before NetworkManager starts up. Works like a
charm.







> - disable mesh on resume, from a powerd-triggered script
>

Does not work, as explained above.







> - blacklist the MAC address so NM ignores it
>
> you win. Yes, every XO has a different MAC address, but you can read
> that on first boot of the OS, and write the NM configuration. See the
> olpc-configure script for examples.
>

Would be awesome. I believe this is the one and only complete solution
possible :)
Could you point me to the suitable (examples) link? I will be heartfully
grateful.



>
> cheers,
>
>
>
> 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
>


Regards,
Ajay
Martin Langhoff
2012-05-02 07:28:49 UTC
Permalink
On Wed, May 2, 2012 at 3:22 AM, Ajay Garg <***@gmail.com> wrote:
> The /etc/powerd/postresume.d/disable_mesh.sh  doesn't work.

So we need to understand why it does not work. Is it a race condition?
Perhaps it is better fixed as a udev script -- triggering when the
device appears.

The step that disable_mesh performs is very important. If you don't
disable it at that level, you haven't disabled mesh at all and all the
problems persist.

>>  - disable mesh on boot
> Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so
> that the effect takes place before NetworkManager starts up. Works like a
> charm.

Ok. Maybe a udev script is a better place.

>>  - disable mesh on resume, from a powerd-triggered script
> Does not work, as explained above.

Right but you MUST find a way to make it work.

>>  - blacklist the MAC address so NM ignores it
>>
>> you win. Yes, every XO has a different MAC address, but you can read
>> that on first boot of the OS, and write the NM configuration. See the
>> olpc-configure script for examples.
>
>
> Would be awesome. I believe this is the one and only complete solution
> possible :)

Careful here! This only hides the device from NM so you don't race with NM.

> Could you point me to the suitable (examples) link? I will be heartfully
> grateful.

look at the latest olpc-configure in git://dev.laptop.org/projects/olpc-utils



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 Abente
2012-05-02 08:07:53 UTC
Permalink
I think (guessing by the responses) the original problem here is that, if
you disable the mesh AFTER NM has taken the device, NM crashes. This a
regression bug, considering that this didn't happened in fedora-11 based
builds.

So the solution here is to find another place to place the script, where it
guarantee that the script will be executed before NM does its job at resume
time.

Another solution is to find out why NM crashes now and why didn't before,
but I wouldn't go that way.

Cheers,


On Wed, May 2, 2012 at 3:28 AM, Martin Langhoff
<***@gmail.com>wrote:

> On Wed, May 2, 2012 at 3:22 AM, Ajay Garg <***@gmail.com> wrote:
> > The /etc/powerd/postresume.d/disable_mesh.sh doesn't work.
>
> So we need to understand why it does not work. Is it a race condition?
> Perhaps it is better fixed as a udev script -- triggering when the
> device appears.
>
> The step that disable_mesh performs is very important. If you don't
> disable it at that level, you haven't disabled mesh at all and all the
> problems persist.
>
> >> - disable mesh on boot
> > Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so
> > that the effect takes place before NetworkManager starts up. Works like a
> > charm.
>
> Ok. Maybe a udev script is a better place.
>
> >> - disable mesh on resume, from a powerd-triggered script
> > Does not work, as explained above.
>
> Right but you MUST find a way to make it work.
>
> >> - blacklist the MAC address so NM ignores it
> >>
> >> you win. Yes, every XO has a different MAC address, but you can read
> >> that on first boot of the OS, and write the NM configuration. See the
> >> olpc-configure script for examples.
> >
> >
> > Would be awesome. I believe this is the one and only complete solution
> > possible :)
>
> Careful here! This only hides the device from NM so you don't race with NM.
>
> > Could you point me to the suitable (examples) link? I will be heartfully
> > grateful.
>
> look at the latest olpc-configure in git://
> dev.laptop.org/projects/olpc-utils
>
>
>
> 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
> _______________________________________________
> Sugar-devel mailing list
> Sugar-***@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
Martin Langhoff
2012-05-02 08:42:11 UTC
Permalink
On Wed, May 2, 2012 at 4:07 AM, Martin Abente
<***@gmail.com> wrote:
> I think (guessing by the responses) the original problem here is that, if
> you disable the mesh AFTER NM has taken the device, NM crashes. This a
> regression bug, considering that this didn't happened in fedora-11 based
> builds.

The timings in F11 builds were completely different. Maybe you were
winning the race that you're now losing.

> So the solution here is to find another place to place the script, where it
> guarantee that the script will be executed before NM does its job at resume
> time.

udev script :-) -- I am pretty sure you can number yourself lower (to
run earlier) than the udev script that fires off the "new device"
event to NM.

> Another solution is to find out why NM crashes now and why didn't before,
> but I wouldn't go that way.

Making NM completely resilient to these race conditions is probably a hard task.

cheers,



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
Jon Nettleton
2012-05-02 09:21:45 UTC
Permalink
On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff
<***@gmail.com> wrote:
> On Wed, May 2, 2012 at 4:07 AM, Martin Abente
> <***@gmail.com> wrote:
>> I think (guessing by the responses) the original problem here is that, if
>> you disable the mesh AFTER NM has taken the device, NM crashes. This a
>> regression bug, considering that this didn't happened in fedora-11 based
>> builds.
>
> The timings in F11 builds were completely different. Maybe you were
> winning the race that you're now losing.
>
>> So the solution here is to find another place to place the script, where it
>> guarantee that the script will be executed before NM does its job at resume
>> time.
>
> udev script :-) -- I am pretty sure you can number yourself lower (to
> run earlier) than the udev script that fires off the "new device"
> event to NM.
>
>> Another solution is to find out why NM crashes now and why didn't before,
>> but I wouldn't go that way.
>
> Making NM completely resilient to these race conditions is probably a hard task.

This is also a temporary solution. There is a kernel patch in 3.1 and
greater kernels that allows you to disable mesh as a kernel module
parameter.

I just played around with the udev script and there definitely seems
to be some timing issues even with that.

-Jon
Martin Abente
2012-05-02 09:31:47 UTC
Permalink
How hard and sensible do you think it could be to backport that patch? :D
(Assuming that touching the kernel is an option for someone, hehe)

On Wed, May 2, 2012 at 5:21 AM, Jon Nettleton <***@gmail.com>wrote:

> On Wed, May 2, 2012 at 10:42 AM, Martin Langhoff
> <***@gmail.com> wrote:
> > On Wed, May 2, 2012 at 4:07 AM, Martin Abente
> > <***@gmail.com> wrote:
> >> I think (guessing by the responses) the original problem here is that,
> if
> >> you disable the mesh AFTER NM has taken the device, NM crashes. This a
> >> regression bug, considering that this didn't happened in fedora-11 based
> >> builds.
> >
> > The timings in F11 builds were completely different. Maybe you were
> > winning the race that you're now losing.
> >
> >> So the solution here is to find another place to place the script,
> where it
> >> guarantee that the script will be executed before NM does its job at
> resume
> >> time.
> >
> > udev script :-) -- I am pretty sure you can number yourself lower (to
> > run earlier) than the udev script that fires off the "new device"
> > event to NM.
> >
> >> Another solution is to find out why NM crashes now and why didn't
> before,
> >> but I wouldn't go that way.
> >
> > Making NM completely resilient to these race conditions is probably a
> hard task.
>
> This is also a temporary solution. There is a kernel patch in 3.1 and
> greater kernels that allows you to disable mesh as a kernel module
> parameter.
>
> I just played around with the udev script and there definitely seems
> to be some timing issues even with that.
>
> -Jon
>
Ajay Garg
2012-05-02 09:32:56 UTC
Permalink
Martin, just one small query :

In one of the earlier mails, it was said that the mac address for "msh0" is
the same as "eth0".
So, would blacklisting the (same) device, be feasible? I mean, would that
not _also_ disable general wifi network detections?


Regards,
Ajay

On Wed, May 2, 2012 at 12:58 PM, Martin Langhoff
<***@gmail.com>wrote:

> On Wed, May 2, 2012 at 3:22 AM, Ajay Garg <***@gmail.com> wrote:
> > The /etc/powerd/postresume.d/disable_mesh.sh doesn't work.
>
> So we need to understand why it does not work. Is it a race condition?
> Perhaps it is better fixed as a udev script -- triggering when the
> device appears.
>
> The step that disable_mesh performs is very important. If you don't
> disable it at that level, you haven't disabled mesh at all and all the
> problems persist.
>
> >> - disable mesh on boot
> > Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so
> > that the effect takes place before NetworkManager starts up. Works like a
> > charm.
>
> Ok. Maybe a udev script is a better place.
>
> >> - disable mesh on resume, from a powerd-triggered script
> > Does not work, as explained above.
>
> Right but you MUST find a way to make it work.
>
> >> - blacklist the MAC address so NM ignores it
> >>
> >> you win. Yes, every XO has a different MAC address, but you can read
> >> that on first boot of the OS, and write the NM configuration. See the
> >> olpc-configure script for examples.
> >
> >
> > Would be awesome. I believe this is the one and only complete solution
> > possible :)
>
> Careful here! This only hides the device from NM so you don't race with NM.
>
> > Could you point me to the suitable (examples) link? I will be heartfully
> > grateful.
>
> look at the latest olpc-configure in git://
> dev.laptop.org/projects/olpc-utils
>
>
>
> 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
2012-05-02 09:41:41 UTC
Permalink
On Wed, May 2, 2012 at 5:32 AM, Ajay Garg <***@gmail.com> wrote:
> In one of the earlier mails, it was said that the mac address for "msh0" is
> the same as "eth0".

Ah, sorry, you're correct, that won't help.

So your options are

- a kernel module parameter, as Jon proposes, in modprobe.d/ or in
the boot commandline

- udev rule / script that triggers before the event is sent to NM




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
Paul Fox
2012-05-02 12:32:45 UTC
Permalink
martin wrote:
> On Wed, May 2, 2012 at 3:22 AM, Ajay Garg <***@gmail.com> wrote:
> > The /etc/powerd/postresume.d/disable_mesh.sh doesn't work.
>
> So we need to understand why it does not work. Is it a race condition?
> Perhaps it is better fixed as a udev script -- triggering when the
> device appears.

i think it's almost a guaranteed race. that script essentially
does this:

while [ ! -f /sys/class/net/eth0/lbs_mesh ]
do
sleep 0.5
done
echo 0 > /sys/class/net/eth0/lbs_mesh

in other words -- the disable_mesh script will discover the disable
node at just about exactly the time that NM discovers the interface.

there's also the "lbs_disablemesh" module parameter, which could be
supplied at initial module load. does that not work, for some reason?
(i seem to recall there may be a problem with it.)

paul

>
> The step that disable_mesh performs is very important. If you don't
> disable it at that level, you haven't disabled mesh at all and all the
> problems persist.
>
> >> - disable mesh on boot
> > Done. Added the 'echo 0' script in 'start()' method of NetworkManager, so
> > that the effect takes place before NetworkManager starts up. Works like a
> > charm.
>
> Ok. Maybe a udev script is a better place.
>
> >> - disable mesh on resume, from a powerd-triggered script
> > Does not work, as explained above.
>
> Right but you MUST find a way to make it work.
>
> >> - blacklist the MAC address so NM ignores it
> >>
> >> you win. Yes, every XO has a different MAC address, but you can read
> >> that on first boot of the OS, and write the NM configuration. See the
> >> olpc-configure script for examples.
> >
> >
> > Would be awesome. I believe this is the one and only complete solution
> > possible :)
>
> Careful here! This only hides the device from NM so you don't race with NM.
>
> > Could you point me to the suitable (examples) link? I will be heartfully
> > grateful.
>
> look at the latest olpc-configure in git://dev.laptop.org/projects/olpc-utils
>
>
>
> 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
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel

=---------------------
paul fox, ***@laptop.org
Ajay Garg
2012-05-02 14:18:11 UTC
Permalink
Good News.

I managed to get this working (albeit via changes in sugar).

The details are at ::
http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632


Regards,
Ajay

On Wed, May 2, 2012 at 6:02 PM, Paul Fox <***@laptop.org> wrote:

> martin wrote:
> > On Wed, May 2, 2012 at 3:22 AM, Ajay Garg <***@gmail.com>
> wrote:
> > > The /etc/powerd/postresume.d/disable_mesh.sh doesn't work.
> >
> > So we need to understand why it does not work. Is it a race condition?
> > Perhaps it is better fixed as a udev script -- triggering when the
> > device appears.
>
> i think it's almost a guaranteed race. that script essentially
> does this:
>
> while [ ! -f /sys/class/net/eth0/lbs_mesh ]
> do
> sleep 0.5
> done
> echo 0 > /sys/class/net/eth0/lbs_mesh
>
> in other words -- the disable_mesh script will discover the disable
> node at just about exactly the time that NM discovers the interface.
>
> there's also the "lbs_disablemesh" module parameter, which could be
> supplied at initial module load. does that not work, for some reason?
> (i seem to recall there may be a problem with it.)
>
> paul
>
> >
> > The step that disable_mesh performs is very important. If you don't
> > disable it at that level, you haven't disabled mesh at all and all the
> > problems persist.
> >
> > >> - disable mesh on boot
> > > Done. Added the 'echo 0' script in 'start()' method of
> NetworkManager, so
> > > that the effect takes place before NetworkManager starts up. Works
> like a
> > > charm.
> >
> > Ok. Maybe a udev script is a better place.
> >
> > >> - disable mesh on resume, from a powerd-triggered script
> > > Does not work, as explained above.
> >
> > Right but you MUST find a way to make it work.
> >
> > >> - blacklist the MAC address so NM ignores it
> > >>
> > >> you win. Yes, every XO has a different MAC address, but you can read
> > >> that on first boot of the OS, and write the NM configuration. See the
> > >> olpc-configure script for examples.
> > >
> > >
> > > Would be awesome. I believe this is the one and only complete solution
> > > possible :)
> >
> > Careful here! This only hides the device from NM so you don't race with
> NM.
> >
> > > Could you point me to the suitable (examples) link? I will be
> heartfully
> > > grateful.
> >
> > look at the latest olpc-configure in git://
> dev.laptop.org/projects/olpc-utils
> >
> >
> >
> > 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
> > _______________________________________________
> > Devel mailing list
> > ***@lists.laptop.org
> > http://lists.laptop.org/listinfo/devel
>
> =---------------------
> paul fox, ***@laptop.org
>
Kevin Gordon
2012-05-02 14:27:03 UTC
Permalink
On Wed, May 2, 2012 at 10:18 AM, Ajay Garg <***@gmail.com> wrote:

> Good News.
>
> I managed to get this working (albeit via changes in sugar).
>
> The details are at ::
>
> http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632
>

I have a couple of minor observations from the great unwashed - yes me.
One is that this solution perhaps wont have any effect when one boots to
the Gnome side. Two, this may be build version dependent, as there would
appear from some of the discussions in the group that there is an effort
for the 12.1.0 builds to more closely link the NM functions on Sugar and
Gnome so that settings are identical when restarting the other
environment. The echo script in boot startup and the corresponding entry
powerd resume , on the other hand, might handle both. Not sure yet, as I'm
still playing with WAP variants, and also, I am the newbie :-)

>
>
> Regards,
> Ajay
>
>
> On Wed, May 2, 2012 at 6:02 PM, Paul Fox <***@laptop.org> wrote:
>
>> martin wrote:
>> > On Wed, May 2, 2012 at 3:22 AM, Ajay Garg <***@gmail.com>
>> wrote:
>> > > The /etc/powerd/postresume.d/disable_mesh.sh doesn't work.
>> >
>> > So we need to understand why it does not work. Is it a race condition?
>> > Perhaps it is better fixed as a udev script -- triggering when the
>> > device appears.
>>
>> i think it's almost a guaranteed race. that script essentially
>> does this:
>>
>> while [ ! -f /sys/class/net/eth0/lbs_mesh ]
>> do
>> sleep 0.5
>> done
>> echo 0 > /sys/class/net/eth0/lbs_mesh
>>
>> in other words -- the disable_mesh script will discover the disable
>> node at just about exactly the time that NM discovers the interface.
>>
>> there's also the "lbs_disablemesh" module parameter, which could be
>> supplied at initial module load. does that not work, for some reason?
>> (i seem to recall there may be a problem with it.)
>>
>> paul
>>
>> >
>> > The step that disable_mesh performs is very important. If you don't
>> > disable it at that level, you haven't disabled mesh at all and all the
>> > problems persist.
>> >
>> > >> - disable mesh on boot
>> > > Done. Added the 'echo 0' script in 'start()' method of
>> NetworkManager, so
>> > > that the effect takes place before NetworkManager starts up. Works
>> like a
>> > > charm.
>> >
>> > Ok. Maybe a udev script is a better place.
>> >
>> > >> - disable mesh on resume, from a powerd-triggered script
>> > > Does not work, as explained above.
>> >
>> > Right but you MUST find a way to make it work.
>> >
>> > >> - blacklist the MAC address so NM ignores it
>> > >>
>> > >> you win. Yes, every XO has a different MAC address, but you can read
>> > >> that on first boot of the OS, and write the NM configuration. See
>> the
>> > >> olpc-configure script for examples.
>> > >
>> > >
>> > > Would be awesome. I believe this is the one and only complete
>> solution
>> > > possible :)
>> >
>> > Careful here! This only hides the device from NM so you don't race
>> with NM.
>> >
>> > > Could you point me to the suitable (examples) link? I will be
>> heartfully
>> > > grateful.
>> >
>> > look at the latest olpc-configure in git://
>> dev.laptop.org/projects/olpc-utils
>> >
>> >
>> >
>> > 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
>> > _______________________________________________
>> > Devel mailing list
>> > ***@lists.laptop.org
>> > http://lists.laptop.org/listinfo/devel
>>
>> =---------------------
>> paul fox, ***@laptop.org
>>
>
>
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
Ajay Garg
2012-05-02 14:29:46 UTC
Permalink
On Wed, May 2, 2012 at 7:57 PM, Kevin Gordon <***@gmail.com> wrote:

>
>
> On Wed, May 2, 2012 at 10:18 AM, Ajay Garg <***@gmail.com> wrote:
>
>> Good News.
>>
>> I managed to get this working (albeit via changes in sugar).
>>
>> The details are at ::
>>
>> http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632
>>
>
> I have a couple of minor observations from the great unwashed - yes me.
> One is that this solution perhaps wont have any effect when one boots to
> the Gnome side.
>

What could be the difference therein? (I could change to one, that could
work in both) :)

Regards,
Ajay


> Two, this may be build version dependent, as there would appear from
> some of the discussions in the group that there is an effort for the 12.1.0
> builds to more closely link the NM functions on Sugar and Gnome so that
> settings are identical when restarting the other environment. The echo
> script in boot startup and the corresponding entry powerd resume , on the
> other hand, might handle both. Not sure yet, as I'm still playing with WAP
> variants, and also, I am the newbie :-)
>
>>
>>
>> Regards,
>> Ajay
>>
>>
>> On Wed, May 2, 2012 at 6:02 PM, Paul Fox <***@laptop.org> wrote:
>>
>>> martin wrote:
>>> > On Wed, May 2, 2012 at 3:22 AM, Ajay Garg <***@gmail.com>
>>> wrote:
>>> > > The /etc/powerd/postresume.d/disable_mesh.sh doesn't work.
>>> >
>>> > So we need to understand why it does not work. Is it a race condition?
>>> > Perhaps it is better fixed as a udev script -- triggering when the
>>> > device appears.
>>>
>>> i think it's almost a guaranteed race. that script essentially
>>> does this:
>>>
>>> while [ ! -f /sys/class/net/eth0/lbs_mesh ]
>>> do
>>> sleep 0.5
>>> done
>>> echo 0 > /sys/class/net/eth0/lbs_mesh
>>>
>>> in other words -- the disable_mesh script will discover the disable
>>> node at just about exactly the time that NM discovers the interface.
>>>
>>> there's also the "lbs_disablemesh" module parameter, which could be
>>> supplied at initial module load. does that not work, for some reason?
>>> (i seem to recall there may be a problem with it.)
>>>
>>> paul
>>>
>>> >
>>> > The step that disable_mesh performs is very important. If you don't
>>> > disable it at that level, you haven't disabled mesh at all and all the
>>> > problems persist.
>>> >
>>> > >> - disable mesh on boot
>>> > > Done. Added the 'echo 0' script in 'start()' method of
>>> NetworkManager, so
>>> > > that the effect takes place before NetworkManager starts up. Works
>>> like a
>>> > > charm.
>>> >
>>> > Ok. Maybe a udev script is a better place.
>>> >
>>> > >> - disable mesh on resume, from a powerd-triggered script
>>> > > Does not work, as explained above.
>>> >
>>> > Right but you MUST find a way to make it work.
>>> >
>>> > >> - blacklist the MAC address so NM ignores it
>>> > >>
>>> > >> you win. Yes, every XO has a different MAC address, but you can
>>> read
>>> > >> that on first boot of the OS, and write the NM configuration. See
>>> the
>>> > >> olpc-configure script for examples.
>>> > >
>>> > >
>>> > > Would be awesome. I believe this is the one and only complete
>>> solution
>>> > > possible :)
>>> >
>>> > Careful here! This only hides the device from NM so you don't race
>>> with NM.
>>> >
>>> > > Could you point me to the suitable (examples) link? I will be
>>> heartfully
>>> > > grateful.
>>> >
>>> > look at the latest olpc-configure in git://
>>> dev.laptop.org/projects/olpc-utils
>>> >
>>> >
>>> >
>>> > 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
>>> > _______________________________________________
>>> > Devel mailing list
>>> > ***@lists.laptop.org
>>> > http://lists.laptop.org/listinfo/devel
>>>
>>> =---------------------
>>> paul fox, ***@laptop.org
>>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> ***@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>>
>
Mikus Grinbergs
2012-05-02 17:33:30 UTC
Permalink
Another comment from the unwashed:

Years back, I used only ethernet to connect my XOs. Nowadays, I'm using
both wired and wireless to connect between XOs. [By the way, I normally
run my XOs with suspend disabled - so I have not paid much attention to
problems associated with 'resume'.]

For about the last year, Network Manager has become "super bossy":

It used to be that if I had an XO on ethernet, Network Manager might
intervene after some 10+ hours - breaking that ethernet connection. I
did not mind occasionally having to "reconnect" the ethernet (I just
invoke a script that re-issues the necessary commands).

But the current Network Manager intervenes in less than ten SECONDS - it
breaks the connection on the ethernet (eth1) interface - presumably to
set up the wireless (eth0) interface (to listen for radio signals).

Bottom line - these days, in order to use ethernet on an XO, I need to
__disable__ Network Manager.

mikus
Martin Langhoff
2012-05-02 14:29:55 UTC
Permalink
On Wed, May 2, 2012 at 10:18 AM, Ajay Garg <***@gmail.com> wrote:
> Good News.
>
> I managed to get this working (albeit via changes in sugar).
>
> The details are at ::
> http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632

The patch seems fairly wrong to me. You are hiding the mesh icons in
sugar, but the mesh is active. Packet forwarding is still happening.

One of the top reasons we stopped using mesh is because it saturates
the RF spectrum, which is a bad thing to do when you have many users
in a small space (ie: in a school).

You had the mesh disable trick working on F11, and (I assume) happy
users of that feature. With this, the feature is broken, but you're
making the UI look right...

cheers,



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
Samuel Greenfeld
2012-05-02 14:54:35 UTC
Permalink
It's worth noting that half the battle can be won by overriding the
following XO-1 specific line in OLPC OS Builder's kspost.50.xo1-tweaks.inc:

gconftool-2 --direct --config-source
xml:readwrite:/etc/gconf/gconf.xml.defaults --type bool --set
/desktop/sugar/network/adhoc false

Setting this to "true", or letting it default to such will show the Ad-hoc
networks by default on XO-1. It also will cause XO-1's to default to
Ad-hoc if no preferred network is found.

The mesh networks will still be there for manual use; but right now they
seem semi-broken anyway on 12.1.0 as we attempt to connect to "Mesh Network
0" and don't set a channel on the Interface.


On Wed, May 2, 2012 at 10:29 AM, Martin Langhoff
<***@gmail.com>wrote:

> On Wed, May 2, 2012 at 10:18 AM, Ajay Garg <***@gmail.com> wrote:
> > Good News.
> >
> > I managed to get this working (albeit via changes in sugar).
> >
> > The details are at ::
> >
> http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632
>
> The patch seems fairly wrong to me. You are hiding the mesh icons in
> sugar, but the mesh is active. Packet forwarding is still happening.
>
> One of the top reasons we stopped using mesh is because it saturates
> the RF spectrum, which is a bad thing to do when you have many users
> in a small space (ie: in a school).
>
> You had the mesh disable trick working on F11, and (I assume) happy
> users of that feature. With this, the feature is broken, but you're
> making the UI look right...
>
> cheers,
>
>
>
> 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
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
Ajay Garg
2012-05-02 15:07:19 UTC
Permalink
On Wed, May 2, 2012 at 7:59 PM, Martin Langhoff
<***@gmail.com>wrote:

> On Wed, May 2, 2012 at 10:18 AM, Ajay Garg <***@gmail.com> wrote:
> > Good News.
> >
> > I managed to get this working (albeit via changes in sugar).
> >
> > The details are at ::
> >
> http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632
>
> The patch seems fairly wrong to me. You are hiding the mesh icons in
> sugar, but the mesh is active. Packet forwarding is still happening.
>


Hmm, ok (didn't know this).

I believe that the number of packets being forwarded in this, would be
(much) less than in the scenario when the users are actually connected to a
mesh-network-channel.
Kindly affirm/reject my above notion :)


Regards,
Ajay



>
> One of the top reasons we stopped using mesh is because it saturates
> the RF spectrum, which is a bad thing to do when you have many users
> in a small space (ie: in a school).
>
> You had the mesh disable trick working on F11, and (I assume) happy
> users of that feature. With this, the feature is broken, but you're
> making the UI look right...
>
> cheers,
>
>
>
> 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
2012-05-02 15:57:50 UTC
Permalink
On Wed, May 2, 2012 at 11:07 AM, Ajay Garg <***@gmail.com> wrote:
> I believe that the number of packets being forwarded in this, would be
> (much) less than in the scenario when the users are actually connected to a
> mesh-network-channel.
> Kindly affirm/reject my above notion :)

I am a very pragmatic man, I would not waste your time if it was a maybe.

There is no "much less" packet forwarding. You get 100% packet forwarding.

And as Sam points out, the "UI" part of it can be set already with a
gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
revert :-(

Don't have the kernel patch info. Maybe look in git for changes in the
libertas driver. It's a pretty low traffic driver, so you'll find it
quick.

cheers,



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
Ajay Garg
2012-05-02 17:31:17 UTC
Permalink
Martin,

just out of curiosity .. a logical query comes to my mind.


Why, and to whom, are packets forwarded, even though no user has joined any
channel?

Please do not take this as arrogance; I just wish to clear up some logical
mind-blocks :D
More importantly, this would clear up some of my networking concepts as
well :D


Thanks in advance for being my teacher :D


Thanks and Regards,
Ajay

On Wed, May 2, 2012 at 9:27 PM, Martin Langhoff
<***@gmail.com>wrote:

> On Wed, May 2, 2012 at 11:07 AM, Ajay Garg <***@gmail.com> wrote:
> > I believe that the number of packets being forwarded in this, would be
> > (much) less than in the scenario when the users are actually connected
> to a
> > mesh-network-channel.
> > Kindly affirm/reject my above notion :)
>
> I am a very pragmatic man, I would not waste your time if it was a maybe.
>
> There is no "much less" packet forwarding. You get 100% packet forwarding.
>
> And as Sam points out, the "UI" part of it can be set already with a
> gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
> revert :-(
>
> Don't have the kernel patch info. Maybe look in git for changes in the
> libertas driver. It's a pretty low traffic driver, so you'll find it
> quick.
>
> cheers,
>
>
>
> 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
>
Paul Fox
2012-05-02 20:51:49 UTC
Permalink
martin wrote:
> On Wed, May 2, 2012 at 11:07 AM, Ajay Garg <***@gmail.com> wrote:
> > I believe that the number of packets being forwarded in this, would be
> > (much) less than in the scenario when the users are actually connected to a
> > mesh-network-channel.
> > Kindly affirm/reject my above notion :)
>
> I am a very pragmatic man, I would not waste your time if it was a maybe.
>
> There is no "much less" packet forwarding. You get 100% packet forwarding.
>
> And as Sam points out, the "UI" part of it can be set already with a
> gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
> revert :-(
>
> Don't have the kernel patch info. Maybe look in git for changes in the
> libertas driver. It's a pretty low traffic driver, so you'll find it
> quick.

i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
did the rest. this implements a new "libertas_disablemesh" module
parameter which should keep mesh from being enabled. please test:

http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm

paul

>
> cheers,
>
>
>
> 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

=---------------------
paul fox, ***@laptop.org
Ajay Garg
2012-05-02 20:54:13 UTC
Permalink
Thanks Paul.
I will test this, and get back to you once done.

Thanks a ton !!!!


Regards,
Ajay

On Thu, May 3, 2012 at 2:21 AM, Paul Fox <***@laptop.org> wrote:
> martin wrote:
>  > On Wed, May 2, 2012 at 11:07 AM, Ajay Garg <***@gmail.com> wrote:
>  > > I believe that the number of packets being forwarded in this, would be
>  > > (much) less than in the scenario when the users are actually connected to a
>  > > mesh-network-channel.
>  > > Kindly affirm/reject my above notion :)
>  >
>  > I am a very pragmatic man, I would not waste your time if it was a maybe.
>  >
>  > There is no "much less" packet forwarding. You get 100% packet forwarding.
>  >
>  > And as Sam points out, the "UI" part of it can be set already with a
>  > gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
>  > revert :-(
>  >
>  > Don't have the kernel patch info. Maybe look in git for changes in the
>  > libertas driver. It's a pretty low traffic driver, so you'll find it
>  > quick.
>
> i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
> did the rest.  this implements a new "libertas_disablemesh" module
> parameter which should keep mesh from being enabled.  please test:
>
>    http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm
>
> paul
>
>  >
>  > cheers,
>  >
>  >
>  >
>  > 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
>
> =---------------------
>  paul fox, ***@laptop.org
Ajay Garg
2012-05-03 03:28:20 UTC
Permalink
Hi all.

One generic query (not necessarily related to NM crash during
resume-upon-suspend) ::

I cannot seem to find any "grub.conf" on my XO-1, wherein I could add
the kernel boot parameter.
So, does XO-1 have any alternative to "grub.conf" ?


Regards,
Ajay

On Thu, May 3, 2012 at 2:24 AM, Ajay Garg <***@gmail.com> wrote:
> Thanks Paul.
> I will test this, and get back to you once done.
>
> Thanks a ton !!!!
>
>
> Regards,
> Ajay
>
> On Thu, May 3, 2012 at 2:21 AM, Paul Fox <***@laptop.org> wrote:
>> martin wrote:
>>  > On Wed, May 2, 2012 at 11:07 AM, Ajay Garg <***@gmail.com> wrote:
>>  > > I believe that the number of packets being forwarded in this, would be
>>  > > (much) less than in the scenario when the users are actually connected to a
>>  > > mesh-network-channel.
>>  > > Kindly affirm/reject my above notion :)
>>  >
>>  > I am a very pragmatic man, I would not waste your time if it was a maybe.
>>  >
>>  > There is no "much less" packet forwarding. You get 100% packet forwarding.
>>  >
>>  > And as Sam points out, the "UI" part of it can be set already with a
>>  > gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
>>  > revert :-(
>>  >
>>  > Don't have the kernel patch info. Maybe look in git for changes in the
>>  > libertas driver. It's a pretty low traffic driver, so you'll find it
>>  > quick.
>>
>> i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
>> did the rest.  this implements a new "libertas_disablemesh" module
>> parameter which should keep mesh from being enabled.  please test:
>>
>>    http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm
>>
>> paul
>>
>>  >
>>  > cheers,
>>  >
>>  >
>>  >
>>  > 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
>>
>> =---------------------
>>  paul fox, ***@laptop.org
Paul Fox
2012-05-03 03:51:57 UTC
Permalink
ajay wrote:
> Hi all.
>
> One generic query (not necessarily related to NM crash during
> resume-upon-suspend) ::
>
> I cannot seem to find any "grub.conf" on my XO-1, wherein I could add
> the kernel boot parameter.
> So, does XO-1 have any alternative to "grub.conf" ?

look at olpc.fth. in /bootpart/boot/olpc.fth.

if this is for libertas_disablemesh, i'd suggest adding that
in modprobe.conf (or whatever the right file is under modprobe*/*
these days).

paul

>
>
> Regards,
> Ajay
>
> On Thu, May 3, 2012 at 2:24 AM, Ajay Garg <***@gmail.com> wrote:
> > Thanks Paul.
> > I will test this, and get back to you once done.
> >
> > Thanks a ton !!!!
> >
> >
> > Regards,
> > Ajay
> >
> > On Thu, May 3, 2012 at 2:21 AM, Paul Fox <***@laptop.org> wrote:
> >> martin wrote:
> >> > On Wed, May 2, 2012 at 11:07 AM, Ajay Garg <***@gmail.com> wrote:
> >> > > I believe that the number of packets being forwarded in this, would be
> >> > > (much) less than in the scenario when the users are actually connected
> to a
> >> > > mesh-network-channel.
> >> > > Kindly affirm/reject my above notion :)
> >> >
> >> > I am a very pragmatic man, I would not waste your time if it was a maybe.
> >> >
> >> > There is no "much less" packet forwarding. You get 100% packet forwarding.
> >> >
> >> > And as Sam points out, the "UI" part of it can be set already with a
> >> > gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
> >> > revert :-(
> >> >
> >> > Don't have the kernel patch info. Maybe look in git for changes in the
> >> > libertas driver. It's a pretty low traffic driver, so you'll find it
> >> > quick.
> >>
> >> i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
> >> did the rest. this implements a new "libertas_disablemesh" module
> >> parameter which should keep mesh from being enabled. please test:
> >>
> >>
> http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde
> 819f.i586.rpm
> >>
> >> paul
> >>
> >> >
> >> > cheers,
> >> >
> >> >
> >> >
> >> > 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
> >>
> >> =---------------------
> >> paul fox, ***@laptop.org

=---------------------
paul fox, ***@laptop.org
Ajay Garg
2012-05-03 05:28:42 UTC
Permalink
Paul, here are the test results ::


== USE-CASE 1 ==

a)
Created file '/etc/modprobe.d/libertas.conf'.


b)
Ensured that '/etc/modprobe.d/libertas.conf' contained only the
following line ::

options libertas libertas_disablemesh=1


c)
Ensured that there is no "echo 0 > "/sys/class/net/eth0/lbs_mesh"
script, anywhere on the XO-1.
This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'.


d)
Rebooted.


e)
Wifi icons were visible in Neighborhood-View, but no mesh-icons were visible.


f)
Upon resume-from-suspend, wifi icons were visible in
Neighborhood-View, but no mesh-icons were visible.


g)
Observations e) and f) were observed, _every single time_.



=================================================================================



== USE-CASE 2 ==

a)
Created file '/etc/modprobe.d/libertas.conf'.


b)
Ensured that '/etc/modprobe.d/libertas.conf' contained only the
following line ::

options libertas libertas_disablemesh=0


c)
Ensured that there is no "echo 0 > "/sys/class/net/eth0/lbs_mesh"
script, anywhere on the XO-1.
This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'.


d)
Rebooted.


e)
Wifi icons, and mesh-icons were visible in Neighborhood-View.


f)
Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.


g)
Observations e) and f) were observed, _every single time_.




=================================================================================



== USE-CASE 3 ==

a)
Ensured that there was no such file, that contained the following line ::

options libertas libertas_disablemesh


b)
Ensured that there is no "echo 0 > "/sys/class/net/eth0/lbs_mesh"
script, anywhere on the XO-1.
This also meant, that there was no '/etc/powerd/postresume.d/disable_mesh.sh'.


c)
Rebooted.


d)
Wifi icons, and mesh-icons were visible in Neighborhood-View.


e)
Upon resume-from-suspend, wifi-icons and mesh-icons were visible in
Neighborhood-View.


f)
Observations d) and e) were observed, _every single time_.






== SUMMARY==

Barring use-case 2 (which looks a bit odd), use-cases 1 and 3 worked
perfectly as expected.
Thanks Paul for your prompt effort in generating the new kernel, with
the patch. Thanks again.





== JUST ONE LAST QUERY ==

Is the "disable-mesh-patch" the only difference between the following ::


kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586
(kernel generated by you)
kernel-2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9.i586
(original kernel present on XO-1)





Thanks again.
The issue stands resolved :)


The new kernel could be deployed, provided the answer to the (last,
only) query is a "yes". :)


Regards,
Ajay





On Thu, May 3, 2012 at 2:21 AM, Paul Fox <***@laptop.org> wrote:
> martin wrote:
>  > On Wed, May 2, 2012 at 11:07 AM, Ajay Garg <***@gmail.com> wrote:
>  > > I believe that the number of packets being forwarded in this, would be
>  > > (much) less than in the scenario when the users are actually connected to a
>  > > mesh-network-channel.
>  > > Kindly affirm/reject my above notion :)
>  >
>  > I am a very pragmatic man, I would not waste your time if it was a maybe.
>  >
>  > There is no "much less" packet forwarding. You get 100% packet forwarding.
>  >
>  > And as Sam points out, the "UI" part of it can be set already with a
>  > gconf setting, via OOB. Unfortunatley, I have to agree with Anish's
>  > revert :-(
>  >
>  > Don't have the kernel patch info. Maybe look in git for changes in the
>  > libertas driver. It's a pretty low traffic driver, so you'll find it
>  > quick.
>
> i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
> did the rest.  this implements a new "libertas_disablemesh" module
> parameter which should keep mesh from being enabled.  please test:
>
>    http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm
>
> paul
>
>  >
>  > cheers,
>  >
>  >
>  >
>  > 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
>
> =---------------------
>  paul fox, ***@laptop.org
James Cameron
2012-05-03 06:09:45 UTC
Permalink
On Thu, May 03, 2012 at 10:58:42AM +0530, Ajay Garg wrote:
> == JUST ONE LAST QUERY ==
>
> Is the "disable-mesh-patch" the only difference between the following ::
>
>
> kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586
> (kernel generated by you)
> kernel-2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9.i586
> (original kernel present on XO-1)

The seven characters between olpc. and .i586 are the git hash for the
olpc-2.6.35 branch in the git repository git://dev.laptop.org/olpc-kernel

These tell you which git hash was used to build the kernel.

The hash c2bd7b9 is two patches away from bde819f in the branch log. [1]

One patch [3] is what Paul did for you. The other patch [2] is XO-1.5
specific.

So for your purposes, yes, it is the only difference.

You can see a list of previous official kernels. [4]

References:

1.
http://dev.laptop.org/git/olpc-kernel/?h=olpc-2.6.35

2.
http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-2.6.35&id=5d76efb5df8c6b1d181c47b17b1d1e9a39ef66b6
ov7670: Disable non-YUV modes on XO-1.5 (#11297)
Non YUV modes cannot be scaled by the via-camera driver without messing
up the colours in the image.

3.
http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-2.6.35&id=bde819fe60fdc8ca7c7d6e0552105d0438cc7f89
libertas: Add libertas_disablemesh module parameter to disable mesh
interfaceolpc-2.6.35
This allows individual users and deployments to disable mesh support at
runtime, i.e. without having to build and maintain a custom kernel.

4.
http://dev.laptop.org/~kernels/f14-xo1/?C=M;O=D

--
James Cameron
http://quozl.linux.org.au/
Ajay Garg
2012-05-03 06:58:44 UTC
Permalink
Thanks James.

A second thanks, for the verbose explanation :) , thus making it
easier for future.
Thanks for your efforts.

Regards,
Ajay

On Thu, May 3, 2012 at 11:39 AM, James Cameron <***@laptop.org> wrote:
> On Thu, May 03, 2012 at 10:58:42AM +0530, Ajay Garg wrote:
>> == JUST ONE LAST QUERY ==
>>
>> Is the "disable-mesh-patch" the only difference between the following ::
>>
>>
>>           kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586
>>             (kernel generated by you)
>>           kernel-2.6.35.13_xo1-20111005.1403.olpc.c2bd7b9.i586
>>             (original kernel present on XO-1)
>
> The seven characters between olpc. and .i586 are the git hash for the
> olpc-2.6.35 branch in the git repository git://dev.laptop.org/olpc-kernel
>
> These tell you which git hash was used to build the kernel.
>
> The hash c2bd7b9 is two patches away from bde819f in the branch log.  [1]
>
> One patch [3] is what Paul did for you.  The other patch [2] is XO-1.5
> specific.
>
> So for your purposes, yes, it is the only difference.
>
> You can see a list of previous official kernels.  [4]
>
> References:
>
> 1.
> http://dev.laptop.org/git/olpc-kernel/?h=olpc-2.6.35
>
> 2.
> http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-2.6.35&id=5d76efb5df8c6b1d181c47b17b1d1e9a39ef66b6
> ov7670: Disable non-YUV modes on XO-1.5 (#11297)
> Non YUV modes cannot be scaled by the via-camera driver without messing
> up the colours in the image.
>
> 3.
> http://dev.laptop.org/git/olpc-kernel/commit/?h=olpc-2.6.35&id=bde819fe60fdc8ca7c7d6e0552105d0438cc7f89
> libertas: Add libertas_disablemesh module parameter to disable mesh
> interfaceolpc-2.6.35
> This allows individual users and deployments to disable mesh support at
> runtime, i.e. without having to build and maintain a custom kernel.
>
> 4.
> http://dev.laptop.org/~kernels/f14-xo1/?C=M;O=D
>
> --
> James Cameron
> http://quozl.linux.org.au/
Sascha Silbe
2012-05-04 20:33:04 UTC
Permalink
Ajay Garg <***@gmail.com> writes:

[...]
> b)
> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
> following line ::
>
> options libertas libertas_disablemesh=0
[...]
> f)
> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.

Interesting.

> g)
> Observations e) and f) were observed, _every single time_.

OK, I suppose you repeated this often enough and using exactly the same
environment and procedures as the other test cases? I.e. you are sure
that it's really specific to libertas_disablemesh=0 rather than just
occurring at random even without the libertas_disablemesh setting or
based on how the suspend / resume was triggered (e.g. idle suspend
vs. lid or power switch)?

I don't see anything in the patch or the module params code that would
explain this behaviour. If it's reproducible, I'll have to dive into it
and debug a bit...

Thanks for testing, BTW!

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/
Ajay Garg
2012-05-04 20:38:53 UTC
Permalink
On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe <***@activitycentral.com> wrote:
> Ajay Garg <***@gmail.com> writes:
>
> [...]
>> b)
>> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
>> following line ::
>>
>>               options libertas libertas_disablemesh=0
> [...]
>> f)
>> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.
>
> Interesting.
>
>> g)
>> Observations e) and f) were observed, _every single time_.
>
> OK, I suppose you repeated this often enough and using exactly the same
> environment and procedures as the other test cases? I.e. you are sure
> that it's really specific to libertas_disablemesh=0 rather than just
> occurring at random even without the libertas_disablemesh setting or
> based on how the suspend / resume was triggered (e.g. idle suspend
> vs. lid or power switch)?

I tried 3 times, and it happened every time. (I tried with the "lid"
approach every time, under identical conditions and set of
procedures.).





>
> I don't see anything in the patch or the module params code that would
> explain this behaviour. If it's reproducible, I'll have to dive into it
> and debug a bit...

It is reproducible every time (at least at my end). :)




>
> Thanks for testing, BTW!

My pleasure :)




>
> Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/


Regards,
Ajay
Martin Abente
2012-05-04 22:12:18 UTC
Permalink
Did you remove the disable mesh.script for the testing?
El may 4, 2012 10:39 p.m., "Ajay Garg" <***@gmail.com> escribió:

> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe <***@activitycentral.com>
> wrote:
> > Ajay Garg <***@gmail.com> writes:
> >
> > [...]
> >> b)
> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
> >> following line ::
> >>
> >> options libertas libertas_disablemesh=0
> > [...]
> >> f)
> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.
> >
> > Interesting.
> >
> >> g)
> >> Observations e) and f) were observed, _every single time_.
> >
> > OK, I suppose you repeated this often enough and using exactly the same
> > environment and procedures as the other test cases? I.e. you are sure
> > that it's really specific to libertas_disablemesh=0 rather than just
> > occurring at random even without the libertas_disablemesh setting or
> > based on how the suspend / resume was triggered (e.g. idle suspend
> > vs. lid or power switch)?
>
> I tried 3 times, and it happened every time. (I tried with the "lid"
> approach every time, under identical conditions and set of
> procedures.).
>
>
>
>
>
> >
> > I don't see anything in the patch or the module params code that would
> > explain this behaviour. If it's reproducible, I'll have to dive into it
> > and debug a bit...
>
> It is reproducible every time (at least at my end). :)
>
>
>
>
> >
> > Thanks for testing, BTW!
>
> My pleasure :)
>
>
>
>
> >
> > Sascha
> >
> > --
> > http://sascha.silbe.org/
> > http://www.infra-silbe.de/
>
>
> Regards,
> Ajay
> _______________________________________________
> Sugar-devel mailing list
> Sugar-***@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
Ajay Garg
2012-05-05 02:20:00 UTC
Permalink
On Sat, May 5, 2012 at 3:42 AM, Martin Abente
<***@gmail.com> wrote:
> Did you remove the disable mesh.script for the testing?

Yes.

Both from ::

a)
my custom added in '/etc/init.d/NetworkManager'.

b)
'/etc/powed/postresume.d/disable_mesh.sh'


Regards,
Ajay
>
> El may 4, 2012 10:39 p.m., "Ajay Garg" <***@gmail.com> escribió:
>>
>> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe <***@activitycentral.com>
>> wrote:
>> > Ajay Garg <***@gmail.com> writes:
>> >
>> > [...]
>> >> b)
>> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
>> >> following line ::
>> >>
>> >>               options libertas libertas_disablemesh=0
>> > [...]
>> >> f)
>> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD VIEW.
>> >
>> > Interesting.
>> >
>> >> g)
>> >> Observations e) and f) were observed, _every single time_.
>> >
>> > OK, I suppose you repeated this often enough and using exactly the same
>> > environment and procedures as the other test cases? I.e. you are sure
>> > that it's really specific to libertas_disablemesh=0 rather than just
>> > occurring at random even without the libertas_disablemesh setting or
>> > based on how the suspend / resume was triggered (e.g. idle suspend
>> > vs. lid or power switch)?
>>
>> I tried 3 times, and it happened every time. (I tried with the "lid"
>> approach every time, under identical conditions and set of
>> procedures.).
>>
>>
>>
>>
>>
>> >
>> > I don't see anything in the patch or the module params code that would
>> > explain this behaviour. If it's reproducible, I'll have to dive into it
>> > and debug a bit...
>>
>> It is reproducible every time (at least at my end). :)
>>
>>
>>
>>
>> >
>> > Thanks for testing, BTW!
>>
>> My pleasure :)
>>
>>
>>
>>
>> >
>> > Sascha
>> >
>> > --
>> > http://sascha.silbe.org/
>> > http://www.infra-silbe.de/
>>
>>
>> Regards,
>> Ajay
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-***@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
Martin Abente
2012-05-05 08:45:44 UTC
Permalink
just in case, did you try this combination:

libertas(without the patch) + disable_mesh.sh(removed) +
resume-from-suspend (?)

IF NM still crashes then we have been looking in the wrong direction, if
not then we need to look deeper into the patch probably (@silbe ;)).

On Fri, May 4, 2012 at 10:20 PM, Ajay Garg <***@gmail.com> wrote:

> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
> <***@gmail.com> wrote:
> > Did you remove the disable mesh.script for the testing?
>
> Yes.
>
> Both from ::
>
> a)
> my custom added in '/etc/init.d/NetworkManager'.
>
> b)
> '/etc/powed/postresume.d/disable_mesh.sh'
>
>
> Regards,
> Ajay
> >
> > El may 4, 2012 10:39 p.m., "Ajay Garg" <***@gmail.com>
> escribió:
> >>
> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe <***@activitycentral.com
> >
> >> wrote:
> >> > Ajay Garg <***@gmail.com> writes:
> >> >
> >> > [...]
> >> >> b)
> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
> >> >> following line ::
> >> >>
> >> >> options libertas libertas_disablemesh=0
> >> > [...]
> >> >> f)
> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD
> VIEW.
> >> >
> >> > Interesting.
> >> >
> >> >> g)
> >> >> Observations e) and f) were observed, _every single time_.
> >> >
> >> > OK, I suppose you repeated this often enough and using exactly the
> same
> >> > environment and procedures as the other test cases? I.e. you are sure
> >> > that it's really specific to libertas_disablemesh=0 rather than just
> >> > occurring at random even without the libertas_disablemesh setting or
> >> > based on how the suspend / resume was triggered (e.g. idle suspend
> >> > vs. lid or power switch)?
> >>
> >> I tried 3 times, and it happened every time. (I tried with the "lid"
> >> approach every time, under identical conditions and set of
> >> procedures.).
> >>
> >>
> >>
> >>
> >>
> >> >
> >> > I don't see anything in the patch or the module params code that would
> >> > explain this behaviour. If it's reproducible, I'll have to dive into
> it
> >> > and debug a bit...
> >>
> >> It is reproducible every time (at least at my end). :)
> >>
> >>
> >>
> >>
> >> >
> >> > Thanks for testing, BTW!
> >>
> >> My pleasure :)
> >>
> >>
> >>
> >>
> >> >
> >> > Sascha
> >> >
> >> > --
> >> > http://sascha.silbe.org/
> >> > http://www.infra-silbe.de/
> >>
> >>
> >> Regards,
> >> Ajay
> >> _______________________________________________
> >> Sugar-devel mailing list
> >> Sugar-***@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>
Ajay Garg
2012-05-05 10:26:44 UTC
Permalink
Well,

I tried once again the "Case 2"; and upon resume-from-suspend, the
icons appeared fine at my end.

So, the problem was at my end.
So, it seems that nothing needs to be done right now.

If I face the unusual result for "Case 2" again, I will post the
"/var/log/messages", which may be scrutinized.
If someone else faces the same, she/he may do the same.

Till that time, I guess nothing needs to be done.

Sorry Sascha, and everyone.

Regards,
Ajay

On Sat, May 5, 2012 at 2:15 PM, Martin Abente
<***@gmail.com> wrote:
> just in case, did you try this combination:
>
> libertas(without the patch) + disable_mesh.sh(removed) + resume-from-suspend
> (?)
>
> IF NM still crashes then we have been looking in the wrong direction, if not
> then we need to look deeper into the patch probably (@silbe ;)).
>
>
> On Fri, May 4, 2012 at 10:20 PM, Ajay Garg <***@gmail.com> wrote:
>>
>> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
>> <***@gmail.com> wrote:
>> > Did you remove the disable mesh.script for the testing?
>>
>> Yes.
>>
>> Both from ::
>>
>> a)
>> my custom added in '/etc/init.d/NetworkManager'.
>>
>> b)
>> '/etc/powed/postresume.d/disable_mesh.sh'
>>
>>
>> Regards,
>> Ajay
>> >
>> > El may 4, 2012 10:39 p.m., "Ajay Garg" <***@gmail.com>
>> > escribió:
>> >>
>> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe
>> >> <***@activitycentral.com>
>> >> wrote:
>> >> > Ajay Garg <***@gmail.com> writes:
>> >> >
>> >> > [...]
>> >> >> b)
>> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
>> >> >> following line ::
>> >> >>
>> >> >>               options libertas libertas_disablemesh=0
>> >> > [...]
>> >> >> f)
>> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD
>> >> >> VIEW.
>> >> >
>> >> > Interesting.
>> >> >
>> >> >> g)
>> >> >> Observations e) and f) were observed, _every single time_.
>> >> >
>> >> > OK, I suppose you repeated this often enough and using exactly the
>> >> > same
>> >> > environment and procedures as the other test cases? I.e. you are sure
>> >> > that it's really specific to libertas_disablemesh=0 rather than just
>> >> > occurring at random even without the libertas_disablemesh setting or
>> >> > based on how the suspend / resume was triggered (e.g. idle suspend
>> >> > vs. lid or power switch)?
>> >>
>> >> I tried 3 times, and it happened every time. (I tried with the "lid"
>> >> approach every time, under identical conditions and set of
>> >> procedures.).
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> > I don't see anything in the patch or the module params code that
>> >> > would
>> >> > explain this behaviour. If it's reproducible, I'll have to dive into
>> >> > it
>> >> > and debug a bit...
>> >>
>> >> It is reproducible every time (at least at my end). :)
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> > Thanks for testing, BTW!
>> >>
>> >> My pleasure :)
>> >>
>> >>
>> >>
>> >>
>> >> >
>> >> > Sascha
>> >> >
>> >> > --
>> >> > http://sascha.silbe.org/
>> >> > http://www.infra-silbe.de/
>> >>
>> >>
>> >> Regards,
>> >> Ajay
>> >> _______________________________________________
>> >> Sugar-devel mailing list
>> >> Sugar-***@lists.sugarlabs.org
>> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
Kevin Gordon
2012-05-05 13:13:10 UTC
Permalink
On Sat, May 5, 2012 at 6:26 AM, Ajay Garg <***@gmail.com> wrote:

> Well,
>
> I tried once again the "Case 2"; and upon resume-from-suspend, the
> icons appeared fine at my end.
>
> So, the problem was at my end.
> So, it seems that nothing needs to be done right now.
>
> If I face the unusual result for "Case 2" again, I will post the
> "/var/log/messages", which may be scrutinized.
> If someone else faces the same, she/he may do the same.
>
> Till that time, I guess nothing needs to be done.
>

Ajay:

Since you've already installed the patch, could I be lazy and ask you a
favour? In the scenario where you have booted with mesh disabled, could
you go over to the Sugar control/panel settings Network applet, turn the
radio off, discard network history, turn the radio back on, wait a bit,
and see what icons appear in the neighbourhood view?

Curious to see what happens here. I'll do some more testing using this
kernel/patch on both gnome and sugar next week, but thought if you had a
few seconds I could get a 'head start' at looking at this situation. If
not, no big deal - what's done is already really neat! Thanks.

Cheers,

KG


> Sorry Sascha, and everyone.
>
> Regards,
> Ajay
>
> On Sat, May 5, 2012 at 2:15 PM, Martin Abente
> <***@gmail.com> wrote:
> > just in case, did you try this combination:
> >
> > libertas(without the patch) + disable_mesh.sh(removed) +
> resume-from-suspend
> > (?)
> >
> > IF NM still crashes then we have been looking in the wrong direction, if
> not
> > then we need to look deeper into the patch probably (@silbe ;)).
> >
> >
> > On Fri, May 4, 2012 at 10:20 PM, Ajay Garg <***@gmail.com>
> wrote:
> >>
> >> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
> >> <***@gmail.com> wrote:
> >> > Did you remove the disable mesh.script for the testing?
> >>
> >> Yes.
> >>
> >> Both from ::
> >>
> >> a)
> >> my custom added in '/etc/init.d/NetworkManager'.
> >>
> >> b)
> >> '/etc/powed/postresume.d/disable_mesh.sh'
> >>
> >>
> >> Regards,
> >> Ajay
> >> >
> >> > El may 4, 2012 10:39 p.m., "Ajay Garg" <***@gmail.com>
> >> > escribió:
> >> >>
> >> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe
> >> >> <***@activitycentral.com>
> >> >> wrote:
> >> >> > Ajay Garg <***@gmail.com> writes:
> >> >> >
> >> >> > [...]
> >> >> >> b)
> >> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
> >> >> >> following line ::
> >> >> >>
> >> >> >> options libertas libertas_disablemesh=0
> >> >> > [...]
> >> >> >> f)
> >> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD
> >> >> >> VIEW.
> >> >> >
> >> >> > Interesting.
> >> >> >
> >> >> >> g)
> >> >> >> Observations e) and f) were observed, _every single time_.
> >> >> >
> >> >> > OK, I suppose you repeated this often enough and using exactly the
> >> >> > same
> >> >> > environment and procedures as the other test cases? I.e. you are
> sure
> >> >> > that it's really specific to libertas_disablemesh=0 rather than
> just
> >> >> > occurring at random even without the libertas_disablemesh setting
> or
> >> >> > based on how the suspend / resume was triggered (e.g. idle suspend
> >> >> > vs. lid or power switch)?
> >> >>
> >> >> I tried 3 times, and it happened every time. (I tried with the "lid"
> >> >> approach every time, under identical conditions and set of
> >> >> procedures.).
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> > I don't see anything in the patch or the module params code that
> >> >> > would
> >> >> > explain this behaviour. If it's reproducible, I'll have to dive
> into
> >> >> > it
> >> >> > and debug a bit...
> >> >>
> >> >> It is reproducible every time (at least at my end). :)
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> > Thanks for testing, BTW!
> >> >>
> >> >> My pleasure :)
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> >
> >> >> > Sascha
> >> >> >
> >> >> > --
> >> >> > http://sascha.silbe.org/
> >> >> > http://www.infra-silbe.de/
> >> >>
> >> >>
> >> >> Regards,
> >> >> Ajay
> >> >> _______________________________________________
> >> >> Sugar-devel mailing list
> >> >> Sugar-***@lists.sugarlabs.org
> >> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
Ajay Garg
2012-05-05 17:57:36 UTC
Permalink
Hi Kevin.

Following are the steps and observations ::

a)
Booted with mesh-disabled (via "options libertas libertas_disablemesh=1").

b)
In Neighborhood-View, "wifi" and three "adhoc" network icons were present.

c)
Then, I turned wifi-radio off, discarded network history. Now, only
three "adhoc" network icons were present in Neighborhood-View.

d)
After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
network icons could be seen.

e)
Again, I turned wifi-radio off, discarded network history. Again, only
three "adhoc" network icons could be seen in Neighborhood-View.

f)
Rebooted.

g)
Only three "adhoc" network icons were seen in Neighborhood-View.

h)
After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
network icons could be seen in Neighborhood-View.


So, it works fine I guess (note that, mesh-icons were NOT seen anytime
in the above steps) :)


Regards,
Ajay

On Sat, May 5, 2012 at 6:43 PM, Kevin Gordon <***@gmail.com> wrote:
>
>
> On Sat, May 5, 2012 at 6:26 AM, Ajay Garg <***@gmail.com> wrote:
>>
>> Well,
>>
>> I tried once again the "Case 2"; and upon resume-from-suspend, the
>> icons appeared fine at my end.
>>
>> So, the problem was at my end.
>> So, it seems that nothing needs to be done right now.
>>
>> If I face the unusual result for "Case 2" again, I will post the
>> "/var/log/messages", which may be scrutinized.
>> If someone else faces the same, she/he may do the same.
>>
>> Till that time, I guess nothing needs to be done.
>
>
> Ajay:
>
> Since you've already installed the patch, could I be lazy and ask you a
> favour?   In the scenario where you have booted with mesh disabled, could
> you go over to the Sugar control/panel settings Network applet, turn the
> radio off,  discard network history, turn the radio back on, wait a bit, and
> see what icons appear in the neighbourhood view?
>
> Curious to see what happens here.  I'll do some more testing using this
> kernel/patch on both gnome and sugar next week, but thought if you had a few
> seconds I could get a 'head start' at looking at this situation.  If not, no
> big deal - what's done is already really neat!  Thanks.
>
> Cheers,
>
> KG
>
>>
>> Sorry Sascha, and everyone.
>>
>> Regards,
>> Ajay
>>
>> On Sat, May 5, 2012 at 2:15 PM, Martin Abente
>> <***@gmail.com> wrote:
>> > just in case, did you try this combination:
>> >
>> > libertas(without the patch) + disable_mesh.sh(removed) +
>> > resume-from-suspend
>> > (?)
>> >
>> > IF NM still crashes then we have been looking in the wrong direction, if
>> > not
>> > then we need to look deeper into the patch probably (@silbe ;)).
>> >
>> >
>> > On Fri, May 4, 2012 at 10:20 PM, Ajay Garg <***@gmail.com>
>> > wrote:
>> >>
>> >> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
>> >> <***@gmail.com> wrote:
>> >> > Did you remove the disable mesh.script for the testing?
>> >>
>> >> Yes.
>> >>
>> >> Both from ::
>> >>
>> >> a)
>> >> my custom added in '/etc/init.d/NetworkManager'.
>> >>
>> >> b)
>> >> '/etc/powed/postresume.d/disable_mesh.sh'
>> >>
>> >>
>> >> Regards,
>> >> Ajay
>> >> >
>> >> > El may 4, 2012 10:39 p.m., "Ajay Garg" <***@gmail.com>
>> >> > escribió:
>> >> >>
>> >> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe
>> >> >> <***@activitycentral.com>
>> >> >> wrote:
>> >> >> > Ajay Garg <***@gmail.com> writes:
>> >> >> >
>> >> >> > [...]
>> >> >> >> b)
>> >> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
>> >> >> >> following line ::
>> >> >> >>
>> >> >> >>               options libertas libertas_disablemesh=0
>> >> >> > [...]
>> >> >> >> f)
>> >> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN NEIGHBORHOOD
>> >> >> >> VIEW.
>> >> >> >
>> >> >> > Interesting.
>> >> >> >
>> >> >> >> g)
>> >> >> >> Observations e) and f) were observed, _every single time_.
>> >> >> >
>> >> >> > OK, I suppose you repeated this often enough and using exactly the
>> >> >> > same
>> >> >> > environment and procedures as the other test cases? I.e. you are
>> >> >> > sure
>> >> >> > that it's really specific to libertas_disablemesh=0 rather than
>> >> >> > just
>> >> >> > occurring at random even without the libertas_disablemesh setting
>> >> >> > or
>> >> >> > based on how the suspend / resume was triggered (e.g. idle suspend
>> >> >> > vs. lid or power switch)?
>> >> >>
>> >> >> I tried 3 times, and it happened every time. (I tried with the "lid"
>> >> >> approach every time, under identical conditions and set of
>> >> >> procedures.).
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > I don't see anything in the patch or the module params code that
>> >> >> > would
>> >> >> > explain this behaviour. If it's reproducible, I'll have to dive
>> >> >> > into
>> >> >> > it
>> >> >> > and debug a bit...
>> >> >>
>> >> >> It is reproducible every time (at least at my end). :)
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > Thanks for testing, BTW!
>> >> >>
>> >> >> My pleasure :)
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > Sascha
>> >> >> >
>> >> >> > --
>> >> >> > http://sascha.silbe.org/
>> >> >> > http://www.infra-silbe.de/
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >> Ajay
>> >> >> _______________________________________________
>> >> >> Sugar-devel mailing list
>> >> >> Sugar-***@lists.sugarlabs.org
>> >> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>> >
>> >
>> _______________________________________________
>> Devel mailing list
>> ***@lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>
>
Ajay Garg
2012-05-10 17:23:24 UTC
Permalink
Hi all.

(Unfortunately) A new use-case has come into effect ::


If I boot with "/security/develop.sig" folder in my pendrive,

a)
mesh-icons are observed in neighborhood-view, both during reboot and
resume-from-suspend.

b)
"/var/log/messages" show the loading of "msh0". However, there are no
exceptions/crash-traces therein.

c)
Also, I see the presence of a folder "/sys/class/net/msh0".




However, if there is no "security/develop.sig" file in my pendrive,

a)
No mesh-icons are seen in neighborhood-view, during reboot or
resume-from-suspend (as expected).

b)
"/var/log/messages" has no mention of "msh0" (as expected).

c)
There is no folder "/sys/class/net/msh0" (i guess that is what is expected).




Is my observation in line with anyone's observation on olpc/sugar?
(Note that the issue was reported by UY deployment; and it could be
reproduced at our end as well).



Kindly reply with comments.



Thanks and Regards,
Ajay





On Sat, May 5, 2012 at 11:27 PM, Ajay Garg <***@gmail.com> wrote:

> Hi Kevin.
>
> Following are the steps and observations ::
>
> a)
> Booted with mesh-disabled (via "options libertas libertas_disablemesh=1").
>
> b)
> In Neighborhood-View, "wifi" and three "adhoc" network icons were present.
>
> c)
> Then, I turned wifi-radio off, discarded network history. Now, only
> three "adhoc" network icons were present in Neighborhood-View.
>
> d)
> After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
> network icons could be seen.
>
> e)
> Again, I turned wifi-radio off, discarded network history. Again, only
> three "adhoc" network icons could be seen in Neighborhood-View.
>
> f)
> Rebooted.
>
> g)
> Only three "adhoc" network icons were seen in Neighborhood-View.
>
> h)
> After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
> network icons could be seen in Neighborhood-View.
>
>
> So, it works fine I guess (note that, mesh-icons were NOT seen anytime
> in the above steps) :)
>
>
> Regards,
> Ajay
>
> On Sat, May 5, 2012 at 6:43 PM, Kevin Gordon <***@gmail.com> wrote:
> >
> >
> > On Sat, May 5, 2012 at 6:26 AM, Ajay Garg <***@gmail.com>
> wrote:
> >>
> >> Well,
> >>
> >> I tried once again the "Case 2"; and upon resume-from-suspend, the
> >> icons appeared fine at my end.
> >>
> >> So, the problem was at my end.
> >> So, it seems that nothing needs to be done right now.
> >>
> >> If I face the unusual result for "Case 2" again, I will post the
> >> "/var/log/messages", which may be scrutinized.
> >> If someone else faces the same, she/he may do the same.
> >>
> >> Till that time, I guess nothing needs to be done.
> >
> >
> > Ajay:
> >
> > Since you've already installed the patch, could I be lazy and ask you a
> > favour? In the scenario where you have booted with mesh disabled, could
> > you go over to the Sugar control/panel settings Network applet, turn the
> > radio off, discard network history, turn the radio back on, wait a bit,
> and
> > see what icons appear in the neighbourhood view?
> >
> > Curious to see what happens here. I'll do some more testing using this
> > kernel/patch on both gnome and sugar next week, but thought if you had a
> few
> > seconds I could get a 'head start' at looking at this situation. If
> not, no
> > big deal - what's done is already really neat! Thanks.
> >
> > Cheers,
> >
> > KG
> >
> >>
> >> Sorry Sascha, and everyone.
> >>
> >> Regards,
> >> Ajay
> >>
> >> On Sat, May 5, 2012 at 2:15 PM, Martin Abente
> >> <***@gmail.com> wrote:
> >> > just in case, did you try this combination:
> >> >
> >> > libertas(without the patch) + disable_mesh.sh(removed) +
> >> > resume-from-suspend
> >> > (?)
> >> >
> >> > IF NM still crashes then we have been looking in the wrong direction,
> if
> >> > not
> >> > then we need to look deeper into the patch probably (@silbe ;)).
> >> >
> >> >
> >> > On Fri, May 4, 2012 at 10:20 PM, Ajay Garg <***@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
> >> >> <***@gmail.com> wrote:
> >> >> > Did you remove the disable mesh.script for the testing?
> >> >>
> >> >> Yes.
> >> >>
> >> >> Both from ::
> >> >>
> >> >> a)
> >> >> my custom added in '/etc/init.d/NetworkManager'.
> >> >>
> >> >> b)
> >> >> '/etc/powed/postresume.d/disable_mesh.sh'
> >> >>
> >> >>
> >> >> Regards,
> >> >> Ajay
> >> >> >
> >> >> > El may 4, 2012 10:39 p.m., "Ajay Garg" <***@gmail.com>
> >> >> > escribió:
> >> >> >>
> >> >> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe
> >> >> >> <***@activitycentral.com>
> >> >> >> wrote:
> >> >> >> > Ajay Garg <***@gmail.com> writes:
> >> >> >> >
> >> >> >> > [...]
> >> >> >> >> b)
> >> >> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only the
> >> >> >> >> following line ::
> >> >> >> >>
> >> >> >> >> options libertas libertas_disablemesh=0
> >> >> >> > [...]
> >> >> >> >> f)
> >> >> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN
> NEIGHBORHOOD
> >> >> >> >> VIEW.
> >> >> >> >
> >> >> >> > Interesting.
> >> >> >> >
> >> >> >> >> g)
> >> >> >> >> Observations e) and f) were observed, _every single time_.
> >> >> >> >
> >> >> >> > OK, I suppose you repeated this often enough and using exactly
> the
> >> >> >> > same
> >> >> >> > environment and procedures as the other test cases? I.e. you are
> >> >> >> > sure
> >> >> >> > that it's really specific to libertas_disablemesh=0 rather than
> >> >> >> > just
> >> >> >> > occurring at random even without the libertas_disablemesh
> setting
> >> >> >> > or
> >> >> >> > based on how the suspend / resume was triggered (e.g. idle
> suspend
> >> >> >> > vs. lid or power switch)?
> >> >> >>
> >> >> >> I tried 3 times, and it happened every time. (I tried with the
> "lid"
> >> >> >> approach every time, under identical conditions and set of
> >> >> >> procedures.).
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> > I don't see anything in the patch or the module params code that
> >> >> >> > would
> >> >> >> > explain this behaviour. If it's reproducible, I'll have to dive
> >> >> >> > into
> >> >> >> > it
> >> >> >> > and debug a bit...
> >> >> >>
> >> >> >> It is reproducible every time (at least at my end). :)
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> > Thanks for testing, BTW!
> >> >> >>
> >> >> >> My pleasure :)
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> > Sascha
> >> >> >> >
> >> >> >> > --
> >> >> >> > http://sascha.silbe.org/
> >> >> >> > http://www.infra-silbe.de/
> >> >> >>
> >> >> >>
> >> >> >> Regards,
> >> >> >> Ajay
> >> >> >> _______________________________________________
> >> >> >> Sugar-devel mailing list
> >> >> >> Sugar-***@lists.sugarlabs.org
> >> >> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >> >
> >> >
> >> _______________________________________________
> >> Devel mailing list
> >> ***@lists.laptop.org
> >> http://lists.laptop.org/listinfo/devel
> >
> >
>
Ajay Garg
2012-05-10 17:41:39 UTC
Permalink
Oops..
please ignore my previous mail.
Instead, this is what the issue is (seems this issue has put me in mental
sleep; I am making stupid, idiotic mistakes) :|

Anyways, here it is .. (again, please ignore my previous mail completely)
::::





If we do the following ::

a)
In OpenFirmware CLI, do

enable-security <my XO-1 serial number>


b)
And there is NOT any "/security/develop.sig" file in my pendrive while
booting.



c)
There is NOT any "/security/develop.sig" file on the XO-1,




it is observed that ::

i)
mesh-icons are observed in neighborhood-view, both during reboot and
resume-from-suspend.

ii)
"/var/log/messages" show the loading of "msh0". However, there are no
exceptions/crash-traces therein.

iii)
Also, I see the presence of a folder "/sys/class/net/msh0".



PLEASE NOTE THAT IF ANY OF a), b) OR c) CONDITIONS ARE NOT MET, THE MESH -
ICONS ARE NOT OBSERVED (AS IS VERY MUCH EXPECTED).



Is my observation in line with anyone's observation on olpc/sugar?
(Note that the issue was reported by UY deployment; and it could be
reproduced at our end as well).



Kindly reply with comments.



Thanks and Regards,
Ajay


On Thu, May 10, 2012 at 10:53 PM, Ajay Garg <***@activitycentral.com>wrote:

> Hi all.
>
> (Unfortunately) A new use-case has come into effect ::
>
>
> If I boot with "/security/develop.sig" folder in my pendrive,
>
> a)
> mesh-icons are observed in neighborhood-view, both during reboot and
> resume-from-suspend.
>
> b)
> "/var/log/messages" show the loading of "msh0". However, there are no
> exceptions/crash-traces therein.
>
> c)
> Also, I see the presence of a folder "/sys/class/net/msh0".
>
>
>
>
> However, if there is no "security/develop.sig" file in my pendrive,
>
> a)
> No mesh-icons are seen in neighborhood-view, during reboot or
> resume-from-suspend (as expected).
>
> b)
> "/var/log/messages" has no mention of "msh0" (as expected).
>
> c)
> There is no folder "/sys/class/net/msh0" (i guess that is what is
> expected).
>
>
>
>
> Is my observation in line with anyone's observation on olpc/sugar?
> (Note that the issue was reported by UY deployment; and it could be
> reproduced at our end as well).
>
>
>
> Kindly reply with comments.
>
>
>
> Thanks and Regards,
> Ajay
>
>
>
>
>
>
> On Sat, May 5, 2012 at 11:27 PM, Ajay Garg <***@gmail.com> wrote:
>
>> Hi Kevin.
>>
>> Following are the steps and observations ::
>>
>> a)
>> Booted with mesh-disabled (via "options libertas libertas_disablemesh=1").
>>
>> b)
>> In Neighborhood-View, "wifi" and three "adhoc" network icons were present.
>>
>> c)
>> Then, I turned wifi-radio off, discarded network history. Now, only
>> three "adhoc" network icons were present in Neighborhood-View.
>>
>> d)
>> After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
>> network icons could be seen.
>>
>> e)
>> Again, I turned wifi-radio off, discarded network history. Again, only
>> three "adhoc" network icons could be seen in Neighborhood-View.
>>
>> f)
>> Rebooted.
>>
>> g)
>> Only three "adhoc" network icons were seen in Neighborhood-View.
>>
>> h)
>> After some time, turned wifi-radio on. Now, "wifi" and three "adhoc"
>> network icons could be seen in Neighborhood-View.
>>
>>
>> So, it works fine I guess (note that, mesh-icons were NOT seen anytime
>> in the above steps) :)
>>
>>
>> Regards,
>> Ajay
>>
>> On Sat, May 5, 2012 at 6:43 PM, Kevin Gordon <***@gmail.com>
>> wrote:
>> >
>> >
>> > On Sat, May 5, 2012 at 6:26 AM, Ajay Garg <***@gmail.com>
>> wrote:
>> >>
>> >> Well,
>> >>
>> >> I tried once again the "Case 2"; and upon resume-from-suspend, the
>> >> icons appeared fine at my end.
>> >>
>> >> So, the problem was at my end.
>> >> So, it seems that nothing needs to be done right now.
>> >>
>> >> If I face the unusual result for "Case 2" again, I will post the
>> >> "/var/log/messages", which may be scrutinized.
>> >> If someone else faces the same, she/he may do the same.
>> >>
>> >> Till that time, I guess nothing needs to be done.
>> >
>> >
>> > Ajay:
>> >
>> > Since you've already installed the patch, could I be lazy and ask you a
>> > favour? In the scenario where you have booted with mesh disabled,
>> could
>> > you go over to the Sugar control/panel settings Network applet, turn the
>> > radio off, discard network history, turn the radio back on, wait a
>> bit, and
>> > see what icons appear in the neighbourhood view?
>> >
>> > Curious to see what happens here. I'll do some more testing using this
>> > kernel/patch on both gnome and sugar next week, but thought if you had
>> a few
>> > seconds I could get a 'head start' at looking at this situation. If
>> not, no
>> > big deal - what's done is already really neat! Thanks.
>> >
>> > Cheers,
>> >
>> > KG
>> >
>> >>
>> >> Sorry Sascha, and everyone.
>> >>
>> >> Regards,
>> >> Ajay
>> >>
>> >> On Sat, May 5, 2012 at 2:15 PM, Martin Abente
>> >> <***@gmail.com> wrote:
>> >> > just in case, did you try this combination:
>> >> >
>> >> > libertas(without the patch) + disable_mesh.sh(removed) +
>> >> > resume-from-suspend
>> >> > (?)
>> >> >
>> >> > IF NM still crashes then we have been looking in the wrong
>> direction, if
>> >> > not
>> >> > then we need to look deeper into the patch probably (@silbe ;)).
>> >> >
>> >> >
>> >> > On Fri, May 4, 2012 at 10:20 PM, Ajay Garg <***@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Sat, May 5, 2012 at 3:42 AM, Martin Abente
>> >> >> <***@gmail.com> wrote:
>> >> >> > Did you remove the disable mesh.script for the testing?
>> >> >>
>> >> >> Yes.
>> >> >>
>> >> >> Both from ::
>> >> >>
>> >> >> a)
>> >> >> my custom added in '/etc/init.d/NetworkManager'.
>> >> >>
>> >> >> b)
>> >> >> '/etc/powed/postresume.d/disable_mesh.sh'
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >> Ajay
>> >> >> >
>> >> >> > El may 4, 2012 10:39 p.m., "Ajay Garg" <***@gmail.com>
>> >> >> > escribió:
>> >> >> >>
>> >> >> >> On Sat, May 5, 2012 at 2:03 AM, Sascha Silbe
>> >> >> >> <***@activitycentral.com>
>> >> >> >> wrote:
>> >> >> >> > Ajay Garg <***@gmail.com> writes:
>> >> >> >> >
>> >> >> >> > [...]
>> >> >> >> >> b)
>> >> >> >> >> Ensured that '/etc/modprobe.d/libertas.conf' contained only
>> the
>> >> >> >> >> following line ::
>> >> >> >> >>
>> >> >> >> >> options libertas libertas_disablemesh=0
>> >> >> >> > [...]
>> >> >> >> >> f)
>> >> >> >> >> Upon resume-from-suspend, NO ICONS COULD BE SEEN IN
>> NEIGHBORHOOD
>> >> >> >> >> VIEW.
>> >> >> >> >
>> >> >> >> > Interesting.
>> >> >> >> >
>> >> >> >> >> g)
>> >> >> >> >> Observations e) and f) were observed, _every single time_.
>> >> >> >> >
>> >> >> >> > OK, I suppose you repeated this often enough and using exactly
>> the
>> >> >> >> > same
>> >> >> >> > environment and procedures as the other test cases? I.e. you
>> are
>> >> >> >> > sure
>> >> >> >> > that it's really specific to libertas_disablemesh=0 rather than
>> >> >> >> > just
>> >> >> >> > occurring at random even without the libertas_disablemesh
>> setting
>> >> >> >> > or
>> >> >> >> > based on how the suspend / resume was triggered (e.g. idle
>> suspend
>> >> >> >> > vs. lid or power switch)?
>> >> >> >>
>> >> >> >> I tried 3 times, and it happened every time. (I tried with the
>> "lid"
>> >> >> >> approach every time, under identical conditions and set of
>> >> >> >> procedures.).
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> >
>> >> >> >> > I don't see anything in the patch or the module params code
>> that
>> >> >> >> > would
>> >> >> >> > explain this behaviour. If it's reproducible, I'll have to dive
>> >> >> >> > into
>> >> >> >> > it
>> >> >> >> > and debug a bit...
>> >> >> >>
>> >> >> >> It is reproducible every time (at least at my end). :)
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Thanks for testing, BTW!
>> >> >> >>
>> >> >> >> My pleasure :)
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Sascha
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > http://sascha.silbe.org/
>> >> >> >> > http://www.infra-silbe.de/
>> >> >> >>
>> >> >> >>
>> >> >> >> Regards,
>> >> >> >> Ajay
>> >> >> >> _______________________________________________
>> >> >> >> Sugar-devel mailing list
>> >> >> >> Sugar-***@lists.sugarlabs.org
>> >> >> >> http://lists.sugarlabs.org/listinfo/sugar-devel
>> >> >
>> >> >
>> >> _______________________________________________
>> >> Devel mailing list
>> >> ***@lists.laptop.org
>> >> http://lists.laptop.org/listinfo/devel
>> >
>> >
>>
>
>
Jerry Vonau
2012-05-10 23:32:44 UTC
Permalink
On Thu, 2012-05-10 at 23:11 +0530, Ajay Garg wrote:
> Oops..
> please ignore my previous mail.
> Instead, this is what the issue is (seems this issue has put me in
> mental sleep; I am making stupid, idiotic mistakes) :|
>
> Anyways, here it is .. (again, please ignore my previous mail
> completely) ::::
>

OK, no problem.

>
>
>
>
> If we do the following ::
>
> a)
> In OpenFirmware CLI, do
>
> enable-security <my XO-1 serial number>
>
>

Now you booing the signed zip files.

> b)
> And there is NOT any "/security/develop.sig" file in my pendrive while
> booting.
>
>
>
> c)
> There is NOT any "/security/develop.sig" file on the XO-1,
>
>

Your still booting signed zip files. If you were to boot with your
develop.sig present does the disabling of the mesh work?

>
>
> it is observed that ::
>
> i)
> mesh-icons are observed in neighborhood-view, both during reboot and
> resume-from-suspend.
>
> ii)
> "/var/log/messages" show the loading of "msh0". However, there are no
> exceptions/crash-traces therein.
>
> iii)
> Also, I see the presence of a folder "/sys/class/net/msh0".
>
>
>
> PLEASE NOTE THAT IF ANY OF a), b) OR c) CONDITIONS ARE NOT MET, THE
> MESH - ICONS ARE NOT OBSERVED (AS IS VERY MUCH EXPECTED).
>
>
>
> Is my observation in line with anyone's observation on olpc/sugar?
> (Note that the issue was reported by UY deployment; and it could be
> reproduced at our end as well).
>
>

How are you introducing the libertas_disablemesh=1 option in the
unlocked boot? Are you using modprobe.d or passing a boot arguement
in /boot/olpc.fth?

Jerry
Martin Langhoff
2012-05-10 22:03:38 UTC
Permalink
On Thu, May 10, 2012 at 1:23 PM, Ajay Garg <***@activitycentral.com> wrote:
> If I boot with "/security/develop.sig" folder in my pendrive,
> a)
> mesh-icons are observed in neighborhood-view, both during reboot and
> resume-from-suspend.

Welcome to the initramfs stage of your journey! When the laptop needs
activation, it loads a different initramfs that among other things
loads the libertas module.

You need to get your /etc/modprobe.d/ files into the initramfs. For
your vanilla build, look into dracut-modules-olpc. If you're hoping to
get this integrated into a build with an alternative initramfs (hint:
Ceibal) that build will have a custom version of dracut-modules-olpc.

That is the right way. When the laptop is in secure mode, olpc.fth is
_ignored_, so no chance to set a kernel cmdline there.

An easier alternative might be to check for those flags under /sys,
and if they are there, rmmod/modprobe libertas for example in
olpc-configure (so during early boot).




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
Ajay Garg
2012-05-12 08:38:18 UTC
Permalink
Thanks Martin.
Very neatly explained !!!! :)

I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
(obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
fetched/read from persistent storage). Mesh-icons were no more visible in
the neighborhood-view (both during reboot, and resume-from-suspend).

But I too felt that this is more of a hack, and not a clean solution.


So, I ventured out exploring dracut.
I created a initramfs image on my home/work laptop, hosting Fedora-14, via
the command ::

"dracut test.img"

and then listed the contents of it

"lsinitrd test.img"

I saw that "/etc/modprobe.d/*" files were a part of "test.img".
So, I think that these files _are_ included as part of the initramfs image,
as per say.


So,

"""
Is this observation (that /etc/modprobe.d/* files are included, as per say)
in line with what is expected?
If yes, that is kind of a relief, since that would mean that only
"/etc/modprobe.d/libertas.conf" is not being included (in initramfs that
is).
"""



Thanks and Regards,
Ajay


On Fri, May 11, 2012 at 3:33 AM, Martin Langhoff
<***@gmail.com>wrote:

> On Thu, May 10, 2012 at 1:23 PM, Ajay Garg <***@activitycentral.com>
> wrote:
> > If I boot with "/security/develop.sig" folder in my pendrive,
> > a)
> > mesh-icons are observed in neighborhood-view, both during reboot and
> > resume-from-suspend.
>
> Welcome to the initramfs stage of your journey! When the laptop needs
> activation, it loads a different initramfs that among other things
> loads the libertas module.
>
> You need to get your /etc/modprobe.d/ files into the initramfs. For
> your vanilla build, look into dracut-modules-olpc. If you're hoping to
> get this integrated into a build with an alternative initramfs (hint:
> Ceibal) that build will have a custom version of dracut-modules-olpc.
>
> That is the right way. When the laptop is in secure mode, olpc.fth is
> _ignored_, so no chance to set a kernel cmdline there.
>
> An easier alternative might be to check for those flags under /sys,
> and if they are there, rmmod/modprobe libertas for example in
> olpc-configure (so during early boot).
>
>
>
>
> 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
>
Ajay Garg
2012-05-12 08:56:18 UTC
Permalink
On Sat, May 12, 2012 at 2:08 PM, Ajay Garg <***@activitycentral.com> wrote:

> Thanks Martin.
> Very neatly explained !!!! :)
>
> I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
> (obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
> fetched/read from persistent storage). Mesh-icons were no more visible in
> the neighborhood-view (both during reboot, and resume-from-suspend).
>
> But I too felt that this is more of a hack, and not a clean solution.
>
>
> So, I ventured out exploring dracut.
> I created a initramfs image on my home/work laptop, hosting Fedora-14, via
> the command ::
>
> "dracut test.img"
>
> and then listed the contents of it
>
> "lsinitrd test.img"
>
> I saw that "/etc/modprobe.d/*" files were a part of "test.img".
> So, I think that these files _are_ included as part of the initramfs
> image, as per say.
>
>
> So,
>
> """
> Is this observation (that /etc/modprobe.d/* files are included, as per
> say) in line with what is expected?
> If yes, that is kind of a relief, since that would mean that only
> "/etc/modprobe.d/libertas.conf" is not being included (in initramfs that
> is).
> """
>

Well, just inspected "lsinitrd olpcrd.img" (assuming "olpcrd.img" _is_ the
initramfs image in the signed build :D )
"olpcrd.img", in fact, does not contain any /etc/modprobe/* files.


Am looking into exploring customized dracut-modules-olpc..


Thanks and Regards,
Ajay



>
>
>
> Thanks and Regards,
> Ajay
>
>
>
> On Fri, May 11, 2012 at 3:33 AM, Martin Langhoff <
> ***@gmail.com> wrote:
>
>> On Thu, May 10, 2012 at 1:23 PM, Ajay Garg <***@activitycentral.com>
>> wrote:
>> > If I boot with "/security/develop.sig" folder in my pendrive,
>> > a)
>> > mesh-icons are observed in neighborhood-view, both during reboot and
>> > resume-from-suspend.
>>
>> Welcome to the initramfs stage of your journey! When the laptop needs
>> activation, it loads a different initramfs that among other things
>> loads the libertas module.
>>
>> You need to get your /etc/modprobe.d/ files into the initramfs. For
>> your vanilla build, look into dracut-modules-olpc. If you're hoping to
>> get this integrated into a build with an alternative initramfs (hint:
>> Ceibal) that build will have a custom version of dracut-modules-olpc.
>>
>> That is the right way. When the laptop is in secure mode, olpc.fth is
>> _ignored_, so no chance to set a kernel cmdline there.
>>
>> An easier alternative might be to check for those flags under /sys,
>> and if they are there, rmmod/modprobe libertas for example in
>> olpc-configure (so during early boot).
>>
>>
>>
>>
>> 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
>>
>
>
Ajay Garg
2012-05-12 09:47:52 UTC
Permalink
Martin,

Some observations ::

a)
All observations (appearance/non-appearance of mesh-icons) is inert to the
presence/absence of the following packages ::

* dracut
* dracut-modules-olpc
* dracut-modules-ceibal


b)
I could only see one initramfs image, on any of the signed/unsigned builds
::

* olpcrd.img (with "initrd.img" being a symbolic link to it)






So, some queries ::


a)
Is the (singular) RAM FS image (olpcrd.img) generated for every kind of
build (but loaded into memory only when ALL of the following are met) ::

* laptop is secured
* image is signed
* there is no developer key, either in pendrive, or on SD
at "/security/develop.sig".


b)
I could not find the place where this (singular) RAM FS image is generated,
in the osbuilder (presumably via dracut).
Doing some greps, gave me the following results ::

##########################################################################################
[***@localhost bleeding-edge]$ grep -r -i -s "initrd" .
./modules/xo1_5/kspost.50.xo15-tweaks.inc: " ${DN}${PN}\initrd.img"
expand$ to ramdisk
./modules/signing/preimage.40.sign-os.sh:if [ -e "$fsmount/boot/initrd.img"
]; then
./modules/signing/preimage.40.sign-os.sh: ./sign-os.sh $okey
$fsmount/boot/initrd.img $fsmount/boot/runrd.zip
./modules/signing/preimage.10.extract.sh:if [ -e "$fsmount/boot/initrd.img"
]; then
./modules/signing/preimage.10.extract.sh: cp $fsmount/boot/initrd.img
$tgt/data.img
./modules/signing/README: - if found, the initramfs at /boot/initrd.img (or
/boot/olpcrd.img) will be
./modules/signing/README:found at /boot/initrd.img will be signed into
runos.zip and runrd.zip
./modules/xo1/kspost.50.xo1-tweaks.inc:# FIXME: old olpc.fth looks for
olpcrd.img, but we now use initrd.img
./modules/xo1/kspost.50.xo1-tweaks.inc:[ -e "/boot/olpcrd.img" ] || ln -s
initrd.img /boot/olpcrd.img




[***@localhost bleeding-edge]$ grep -r -i -s "olpcrd" .
./modules/signing/preimage.10.extract.sh:elif [ -e
"$fsmount/boot/olpcrd.img" ]; then
./modules/signing/preimage.10.extract.sh: cp $fsmount/boot/olpcrd.img
$tgt/data.img
./modules/signing/README: - if found, the initramfs at /boot/initrd.img (or
/boot/olpcrd.img) will be
./modules/xo1/kspost.50.xo1-tweaks.inc:# FIXME: old olpc.fth looks for
olpcrd.img, but we now use initrd.img
./modules/xo1/kspost.50.xo1-tweaks.inc:[ -e "/boot/olpcrd.img" ] || ln -s
initrd.img /boot/olpcrd.img
./modules/xo1/kspost.50.xo1-tweaks.inc: " ${DN}${PN}\olpcrd.img" expand$
to ramdisk
##########################################################################################



Looking forward to a reply (especially to the first query).



Thanks and Regards,
Ajay


On Sat, May 12, 2012 at 2:26 PM, Ajay Garg <***@activitycentral.com> wrote:

>
>
> On Sat, May 12, 2012 at 2:08 PM, Ajay Garg <***@activitycentral.com>wrote:
>
>> Thanks Martin.
>> Very neatly explained !!!! :)
>>
>> I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
>> (obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
>> fetched/read from persistent storage). Mesh-icons were no more visible in
>> the neighborhood-view (both during reboot, and resume-from-suspend).
>>
>> But I too felt that this is more of a hack, and not a clean solution.
>>
>>
>> So, I ventured out exploring dracut.
>> I created a initramfs image on my home/work laptop, hosting Fedora-14,
>> via the command ::
>>
>> "dracut test.img"
>>
>> and then listed the contents of it
>>
>> "lsinitrd test.img"
>>
>> I saw that "/etc/modprobe.d/*" files were a part of "test.img".
>> So, I think that these files _are_ included as part of the initramfs
>> image, as per say.
>>
>>
>> So,
>>
>> """
>> Is this observation (that /etc/modprobe.d/* files are included, as per
>> say) in line with what is expected?
>> If yes, that is kind of a relief, since that would mean that only
>> "/etc/modprobe.d/libertas.conf" is not being included (in initramfs that
>> is).
>> """
>>
>
> Well, just inspected "lsinitrd olpcrd.img" (assuming "olpcrd.img" _is_ the
> initramfs image in the signed build :D )
> "olpcrd.img", in fact, does not contain any /etc/modprobe/* files.
>
>
> Am looking into exploring customized dracut-modules-olpc..
>
>
> Thanks and Regards,
> Ajay
>
>
>
>>
>>
>>
>> Thanks and Regards,
>> Ajay
>>
>>
>>
>> On Fri, May 11, 2012 at 3:33 AM, Martin Langhoff <
>> ***@gmail.com> wrote:
>>
>>> On Thu, May 10, 2012 at 1:23 PM, Ajay Garg <***@activitycentral.com>
>>> wrote:
>>> > If I boot with "/security/develop.sig" folder in my pendrive,
>>> > a)
>>> > mesh-icons are observed in neighborhood-view, both during reboot and
>>> > resume-from-suspend.
>>>
>>> Welcome to the initramfs stage of your journey! When the laptop needs
>>> activation, it loads a different initramfs that among other things
>>> loads the libertas module.
>>>
>>> You need to get your /etc/modprobe.d/ files into the initramfs. For
>>> your vanilla build, look into dracut-modules-olpc. If you're hoping to
>>> get this integrated into a build with an alternative initramfs (hint:
>>> Ceibal) that build will have a custom version of dracut-modules-olpc.
>>>
>>> That is the right way. When the laptop is in secure mode, olpc.fth is
>>> _ignored_, so no chance to set a kernel cmdline there.
>>>
>>> An easier alternative might be to check for those flags under /sys,
>>> and if they are there, rmmod/modprobe libertas for example in
>>> olpc-configure (so during early boot).
>>>
>>>
>>>
>>>
>>> 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
2012-05-12 19:20:03 UTC
Permalink
On Sat, May 12, 2012 at 4:38 AM, Ajay Garg <***@activitycentral.com> wrote:
> I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
> (obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
> fetched/read from persistent storage). Mesh-icons were no more visible in
> the neighborhood-view (both during reboot, and resume-from-suspend).
>
> But I too felt that this is more of a hack, and not a clean solution.

Well, as you pointed out in later emails, the initramfs generation
will pick it up from there. I'd forgotten about that -- sorry.

So what you want to do is get libertas.conf into some package
(olpc-utils) or install it from an OOB module -- the xo1 module is a
good candidate.

In fact I'm liking the OOB module option. I think we would accept a
patch to OOB's xo1 module, where based on an option it creates this
file. Just have to make sure it's created before dracut is used to
generate the initramfs.

A bit late, but we may be able to land it for 12.1.0 (or later for 12.2.0).

cheers,



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
Jerry Vonau
2012-05-12 21:40:03 UTC
Permalink
On Sat, 2012-05-12 at 15:20 -0400, Martin Langhoff wrote:
> On Sat, May 12, 2012 at 4:38 AM, Ajay Garg <***@activitycentral.com> wrote:
> > I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
> > (obviously because, this time the "/etc.modprobe.d/libertas.conf" could be
> > fetched/read from persistent storage). Mesh-icons were no more visible in
> > the neighborhood-view (both during reboot, and resume-from-suspend).
> >
> > But I too felt that this is more of a hack, and not a clean solution.
>
> Well, as you pointed out in later emails, the initramfs generation
> will pick it up from there. I'd forgotten about that -- sorry.
>
> So what you want to do is get libertas.conf into some package
> (olpc-utils) or install it from an OOB module -- the xo1 module is a
> good candidate.
>
> In fact I'm liking the OOB module option. I think we would accept a
> patch to OOB's xo1 module, where based on an option it creates this
> file. Just have to make sure it's created before dracut is used to
> generate the initramfs.
>

Hi Martin:

Don't think OOB is used to generate the initramfs, from the kernel spec
file:

# set to 1 to build the initramfs during kernel-build time
# set to 0 to build the initramfs during %post on the host
%define buildinitramfs 1

Doesn't that mean the kernel rpm provides pre-build initrd<version>.img
and actrd<version>.img? Doesn't OOB just sign what is in the kernel rpm?

Think you would need to re-create initrd.img as needed then place the
revised initrd.img into the image via OOB, to be signed by OOB.

Jerry
Ajay Garg
2012-05-13 15:52:23 UTC
Permalink
Thanks Martin and Jerry.

I followed the following steps ::

a)
Listed "lsinitrd /boot/initrd.img".
It did not show any "/etc/modprobe.d/libertas.conf".


b)
Extracted "/boot/initrd.img" into a temporary folder.
Obviously, no "/etc/modprobe.d/libertas.conf" was seen.


c)
Generated the required "/etc/modprobe.d/libertas.conf" with the content
"options libertas libertas_disablemesh=1" in the tmp folder.


d)
Re-compressed the temp-folder to "/boot/initrd.img".


e)
Listed "lsinitrd /boot/initrd.img".
This time, "/etc/modprobe.d/libertas.conf" was listed.


f)
Rebooted XO-1.


g)
Mesh-icons were still observed :(


h)
Note that I did this, without OOB (i.e. I was just wanting to test that
whether this would work at all).


I guess that there is something else we might be missing.


So, I think that the only solution left now, is to put the "rmmod/modprobe"
hack in olpc-configure.

Would it be an acceptable upstream solution (the change in olpc-utils) ?
Martin (Langhoff) / Daniel (Drake) ?



Looking forward to comments and replies.


Thanks and Regards,
Ajay

On Sun, May 13, 2012 at 3:10 AM, Jerry Vonau <***@shaw.ca> wrote:

> On Sat, 2012-05-12 at 15:20 -0400, Martin Langhoff wrote:
> > On Sat, May 12, 2012 at 4:38 AM, Ajay Garg <***@activitycentral.com>
> wrote:
> > > I tried the "rmmod/modprobe" hack in "olpc-configure", and it worked
> > > (obviously because, this time the "/etc.modprobe.d/libertas.conf"
> could be
> > > fetched/read from persistent storage). Mesh-icons were no more visible
> in
> > > the neighborhood-view (both during reboot, and resume-from-suspend).
> > >
> > > But I too felt that this is more of a hack, and not a clean solution.
> >
> > Well, as you pointed out in later emails, the initramfs generation
> > will pick it up from there. I'd forgotten about that -- sorry.
> >
> > So what you want to do is get libertas.conf into some package
> > (olpc-utils) or install it from an OOB module -- the xo1 module is a
> > good candidate.
> >
> > In fact I'm liking the OOB module option. I think we would accept a
> > patch to OOB's xo1 module, where based on an option it creates this
> > file. Just have to make sure it's created before dracut is used to
> > generate the initramfs.
> >
>
> Hi Martin:
>
> Don't think OOB is used to generate the initramfs, from the kernel spec
> file:
>
> # set to 1 to build the initramfs during kernel-build time
> # set to 0 to build the initramfs during %post on the host
> %define buildinitramfs 1
>
> Doesn't that mean the kernel rpm provides pre-build initrd<version>.img
> and actrd<version>.img? Doesn't OOB just sign what is in the kernel rpm?
>
> Think you would need to re-create initrd.img as needed then place the
> revised initrd.img into the image via OOB, to be signed by OOB.
>
> Jerry
>
>
>
Martin Langhoff
2012-05-13 17:28:42 UTC
Permalink
On Sat, May 12, 2012 at 5:40 PM, Jerry Vonau <***@shaw.ca> wrote:
> Don't think OOB is used to generate the initramfs, from the kernel spec
> file:

You are correct as to current state of play. It _used_ to be generated
during the OOB run. Now it is build during the kernel build.

This makes things rather tricky -- currently to get a kernel driver
param such as this one you need to install it _on the machine where
you build your kernel rpm_. This is at best awkward -- the kernel
build environment better be a chroot :-/

So currently Ajay will need to rebuild the kernel rpm in a chroot
where he has installed that libertas.conf he desires. Luckily, we don'
t mess with this too much.

At some point however, I hope that hacking in the initrd gets a bit
more practical.

cheers,



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
Sascha Silbe
2012-05-14 08:26:25 UTC
Permalink
[CC -= sugar-devel]

Martin Langhoff <***@gmail.com> writes:

> This makes things rather tricky -- currently to get a kernel driver
> param such as this one you need to install it _on the machine where
> you build your kernel rpm_. This is at best awkward -- the kernel
> build environment better be a chroot :-/

Ouch. That means we'll have to build our own kernel, and even with a
manual procedure (inside a specially prepared chroot). The reason we
were still using the /sys/class/net/eth0/lbs_mesh hack was that we
didn't want to fork the upstream (OLPC) kernel. Kernel updates usually
have a good reason, so they should spread automatically to all systems
in the field.

Maybe we should consider something like modifying the initrd
(initramfs?) from within some script in olpc-os-builder. Append the
module config file to the existing, already installed initrd. We'd also
need to add in some hook that runs when the kernel RPM gets updated
(which, I assume, means that the initrd gets replaced as well) so that
live updates retain our modification.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/
James Cameron
2012-05-14 08:32:12 UTC
Permalink
Are there any deployments that still want the mesh to work? It might
be simpler to pull it out now, given that only XO-1 supports it.

--
James Cameron
http://quozl.linux.org.au/
Jerry Vonau
2012-05-14 08:53:51 UTC
Permalink
On Mon, 2012-05-14 at 18:32 +1000, James Cameron wrote:
> Are there any deployments that still want the mesh to work? It might
> be simpler to pull it out now, given that only XO-1 supports it.
>

+1 Given that the mesh layout was intended to work with the XS's Active
Antenna which isn't being developed anymore.

Guess the 2 AAs that I have are collector items now.

Jerry
Anish Mangal
2012-05-14 09:11:05 UTC
Permalink
On Mon, May 14, 2012 at 2:02 PM, James Cameron <***@laptop.org> wrote:
> Are there any deployments that still want the mesh to work?  It might
> be simpler to pull it out now, given that only XO-1 supports it.
>

FWIW, Py, Uy, don't want or use it. AU uses only xo-1.5's so no mesh.

+1 from me to disable this by default on the XO-1.

> --
> James Cameron
> http://quozl.linux.org.au/
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
Martin Langhoff
2012-05-14 12:28:16 UTC
Permalink
On Mon, May 14, 2012 at 5:11 AM, Anish Mangal <***@activitycentral.com> wrote:
> On Mon, May 14, 2012 at 2:02 PM, James Cameron <***@laptop.org> wrote:
>> Are there any deployments that still want the mesh to work?  It might
>> be simpler to pull it out now, given that only XO-1 supports it.
> FWIW, Py, Uy, don't want or use it. AU uses only xo-1.5's so no mesh.
>
> +1 from me to disable this by default on the XO-1.

I am partially for this as well, but we need to think it through.

cheers,


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
Daniel Drake
2012-05-14 14:16:05 UTC
Permalink
On Mon, May 14, 2012 at 2:32 AM, James Cameron <***@laptop.org> wrote:
> Are there any deployments that still want the mesh to work?  It might
> be simpler to pull it out now, given that only XO-1 supports it.

The XO-1 mesh is significantly more reliable than marvell wifi's
implementation of ad-hoc. It should stay enabled by default until we
have a less broken ad-hoc implementation, in the interests of having
serverless collaboration.

Daniel
Ajay Garg
2012-05-23 11:51:17 UTC
Permalink
Hi all.

Here is the latest update.

We got the following two patches tested by Ceibal ::


a)
0001-TEST-See-if-this-works-for-the-mesh-issue-on-signed-.patch

This patch, adds "/etc/modprobe.d/libertas.conf" to the initramfs image
(unarchiving, adding and archiving during OOB stage).
Unfortunately, this does not seem to work.

We could debug it more, but I fear that that would inevitably mean
modifying the initramfs a fair bit. Since, we are talking at the kernel
level, modifying initramfs even a bit too much, would require exponential
more testing.

Lucking, we have a simple, clean, understood and guaranteed-to-work
solution.




b)
0001-olpc-configure-Reloading-libertas-and-dependent-usb8.patch

(As already stated in earlier mails) This patch reloads the libertas (and
the dependent usb8xxx driver) during intial boot, which mounts the
secondary-storage-based-filesystem. This time, the rules from
/etc/modprobe.d/* are read, and the mesh is appropriately disabled via the
"libertas_disablemesh" KLM parameter.

So, it would be good if this is included upstream.


For brevity, I am re-attaching the two patches.


Thanks and Regards,
Ajay
Sascha Silbe
2012-05-14 08:08:05 UTC
Permalink
Ajay Garg <***@gmail.com> writes:

> I tried once again the "Case 2"; and upon resume-from-suspend, the
> icons appeared fine at my end.

OK, that's good and bad. Good in the sense that my patch may not be to
blame; bad in that you encountered a problem that couldn't be
reproduced. It may come back later and bite us twice as hard.


> If I face the unusual result for "Case 2" again, I will post the
> "/var/log/messages", which may be scrutinized.

Please also check for and save core dumps. Not sure they'll be generated
by default for system daemons (I'm thinking NetworkManager in
particular). If they aren't, we should investigate how to enable them
globally in our development builds.

Manuel Kaufmann pointed out (in another thread) that there's
olpc-log. We (= AC) should take a closer look at it [1] and see if we
can extend it to provide a complete snapshot for debugging. Having a
single command that always saves all of the information that may be
needed would reduce the chance of forgetting anything.

Sascha

[1] https://dev.laptop.org/git/projects/olpc-netutils/tree/usr/bin/olpc-log
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
Sascha Silbe
2012-05-04 20:16:33 UTC
Permalink
Paul Fox <***@laptop.org> writes:

> i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
> did the rest. this implements a new "libertas_disablemesh" module
> parameter which should keep mesh from being enabled. please test:
>
> http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm

Thanks! Just to be sure: as it's been merged into olpc-2.6.35, all
future official 2.6.35 based OLPC kernel builds will include this patch?

The reason we've not gone the module parameter route so far (in
Dextrose 3) is that we didn't want to divert from upstream (OLPC in this
case) on the kernel level. If it's included now, that concern is
addressed and we can go this route, which IMO is technically the best
option. It avoids all possible race conditions and only needs a single
configuration file to be set up.

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/
Paul Fox
2012-05-04 20:41:38 UTC
Permalink
sascha wrote:
>
> > i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
> > did the rest. this implements a new "libertas_disablemesh" module
> > parameter which should keep mesh from being enabled. please test:
> >
> > http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm
>
> Thanks! Just to be sure: as it's been merged into olpc-2.6.35, all
> future official 2.6.35 based OLPC kernel builds will include this patch?

hi sascha --

yes. i think we hope there won't actually be any more of those, but
if there are, that patch will be there. current and future releases
get the patch for free, since it's upstream. (thank you)

paul

p.s. somehow the git hash i pasted above is incorrect. the correct
cherry-pick was this one:
---------
commit 6bdbdbf4a151a3a1333818cd17a7d7795e936041
Author: Sascha Silbe <***@activitycentral.com>
Date: Wed May 11 14:52:34 2011 +0200

libertas: Add libertas_disablemesh module parameter to disable mesh
interface

This allows individual users and deployments to disable mesh support at
runtime, i.e. without having to build and maintain a custom kernel.

Based on a patch by Paul Fox <***@laptop.org>.
Signed-off-by: Sascha Silbe <***@activitycentral.com>
Signed-off-by: John W. Linville <***@tuxdriver.com>
---------


>
> The reason we've not gone the module parameter route so far (in
> Dextrose 3) is that we didn't want to divert from upstream (OLPC in this
> case) on the kernel level. If it's included now, that concern is
> addressed and we can go this route, which IMO is technically the best
> option. It avoids all possible race conditions and only needs a single
> configuration file to be set up.
>
> Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/

=---------------------
paul fox, ***@laptop.org
Kevin Gordon
2012-05-05 15:58:19 UTC
Permalink
On Fri, May 4, 2012 at 4:41 PM, Paul Fox <***@laptop.org> wrote:

> sascha wrote:
> >
> > > i've cherry-picked 65a5f2b3 onto olpc-2.6.35, and the autobuilder
> > > did the rest. this implements a new "libertas_disablemesh" module
> > > parameter which should keep mesh from being enabled. please test:
> > >
> > >
> http://rpmdropbox.laptop.org/f14-xo1/kernel-2.6.35.13_xo1-20120502.1603.olpc.bde819f.i586.rpm
> >
> > Thanks! Just to be sure: as it's been merged into olpc-2.6.35, all
> > future official 2.6.35 based OLPC kernel builds will include this patch?
>
> hi sascha --
>
> yes. i think we hope there won't actually be any more of those, but
> if there are, that patch will be there. current and future releases
> get the patch for free, since it's upstream. (thank you)
>

Just because I like to inquire on what to many is the obvious :-) ... this
change is *not* upstream for the 12.1.0 XO1.0 current and future kernels
though, correct?

KG



> paul
>
> p.s. somehow the git hash i pasted above is incorrect. the correct
> cherry-pick was this one:
> ---------
> commit 6bdbdbf4a151a3a1333818cd17a7d7795e936041
> Author: Sascha Silbe <***@activitycentral.com>
> Date: Wed May 11 14:52:34 2011 +0200
>
> libertas: Add libertas_disablemesh module parameter to disable mesh
> interface
>
> This allows individual users and deployments to disable mesh support at
> runtime, i.e. without having to build and maintain a custom kernel.
>
> Based on a patch by Paul Fox <***@laptop.org>.
> Signed-off-by: Sascha Silbe <***@activitycentral.com>
> Signed-off-by: John W. Linville <***@tuxdriver.com>
> ---------
>
>
> >
> > The reason we've not gone the module parameter route so far (in
> > Dextrose 3) is that we didn't want to divert from upstream (OLPC in
> this
> > case) on the kernel level. If it's included now, that concern is
> > addressed and we can go this route, which IMO is technically the best
> > option. It avoids all possible race conditions and only needs a single
> > configuration file to be set up.
> >
> > Sascha
> >
> > --
> > http://sascha.silbe.org/
> > http://www.infra-silbe.de/
>
> =---------------------
> paul fox, ***@laptop.org
>
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
Paul Fox
2012-05-05 17:04:45 UTC
Permalink
Sascha Silbe
2012-05-14 08:11:01 UTC
Permalink
Paul Fox <***@foxharp.boston.ma.us> writes:

> yes. i think we hope there won't actually be any more of those, but
> if there are, that patch will be there.

Great, thanks!

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/
Anish Mangal
2012-05-02 15:14:30 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/02/2012 07:59 PM, Martin Langhoff wrote:
> On Wed, May 2, 2012 at 10:18 AM, Ajay Garg <***@gmail.com>
> wrote:
>> Good News.
>>
>> I managed to get this working (albeit via changes in sugar).
>>
>> The details are at ::
>> http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632
>
>>
> The patch seems fairly wrong to me. You are hiding the mesh icons
> in sugar, but the mesh is active. Packet forwarding is still
> happening.
>
> One of the top reasons we stopped using mesh is because it
> saturates the RF spectrum, which is a bad thing to do when you have
> many users in a small space (ie: in a school).
>
> You had the mesh disable trick working on F11, and (I assume)
> happy users of that feature. With this, the feature is broken, but
> you're making the UI look right...
>

I agree.

The *problem* we are trying to solve is not to have a pretty
mesh-icon-free-UI (which is a side effect), but disable the mesh at a
hardware level.

This patch *won't* solve the problem, as it will still flood the air
with packet forwarding.

-
Ajay Garg
2012-05-02 15:43:27 UTC
Permalink
Well, could someone point me to the kernel fix, which could solve the
problem by backporting.
That should be an interesting exercise.

Regards,
Ajay

On Wed, May 2, 2012 at 8:44 PM, Anish Mangal <***@activitycentral.com>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/02/2012 07:59 PM, Martin Langhoff wrote:
> > On Wed, May 2, 2012 at 10:18 AM, Ajay Garg <***@gmail.com>
> > wrote:
> >> Good News.
> >>
> >> I managed to get this working (albeit via changes in sugar).
> >>
> >> The details are at ::
> >>
> http://git.sugarlabs.org/dextrose/mainline/commit/4ac1a5300f4c43608b0f009a23d966d404a15632
> >
> >>
> > The patch seems fairly wrong to me. You are hiding the mesh icons
> > in sugar, but the mesh is active. Packet forwarding is still
> > happening.
> >
> > One of the top reasons we stopped using mesh is because it
> > saturates the RF spectrum, which is a bad thing to do when you have
> > many users in a small space (ie: in a school).
> >
> > You had the mesh disable trick working on F11, and (I assume)
> > happy users of that feature. With this, the feature is broken, but
> > you're making the UI look right...
> >
>
> I agree.
>
> The *problem* we are trying to solve is not to have a pretty
> mesh-icon-free-UI (which is a side effect), but disable the mesh at a
> hardware level.
>
> This patch *won't* solve the problem, as it will still flood the air
> with packet forwarding.
>
Anish Mangal
2012-05-02 06:28:15 UTC
Permalink
On Wed, May 2, 2012 at 11:49 AM, Martin Langhoff
<***@gmail.com> wrote:
> On Wed, May 2, 2012 at 12:13 AM, Ajay Garg <***@gmail.com> wrote:
>> Just that, we do not wish to set up a mesh-network, as per say.
>
> I think you are missing the background reason here. AFAIK, reasons to
> disable mesh network on XO-1:
>
>  - Mesh can easily saturate RF, so dense usage scenarios (schools!)
> benefit from switching it off.
>
>  - Easier out-of-the-box interop with later XO-1.x models, where the
> "under a tree" network uses ad-hoc 802.11g.
>

+1, this was the reason

>> By removing all references to the device, we could provide a "soft" solution
>
> Nah, messing with Sugar code is the wrong solution.
>
>
>
> 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
> _______________________________________________
> Sugar-devel mailing list
> Sugar-***@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
Anish Mangal
2012-05-02 04:16:03 UTC
Permalink
On Wed 02 May 2012 09:39:50 AM IST, James Cameron wrote:
> On Wed, May 02, 2012 at 09:33:36AM +0530, Ajay Garg wrote:
>> Thanks James for the reply.
>>
>> On Wed, May 2, 2012 at 9:21 AM, James Cameron <***@laptop.org> wrote:
>>
>> On Wed, May 02, 2012 at 09:14:26AM +0530, Ajay Garg wrote:
>> > Is there an already tested-cum-recommended method, that could disable
>> > mesh-network, both during reboots and resume-from-suspend?
>>
>> Not that I know of.
>>
>> But I'm curious, why do you need to do this? Is there some other
>> problem you think you will solve with this? There might be an alternate
>> solution.
>>
>>
>> No, nothing of that sort.
>> Just wish to remove the mesh-icons from Neighborhood-View.
>
> But why?
>

Because it isn't really used much. Sugar supports adhoc networking
(since 0.88, IIRC) and that is used instead (atleast in dextrose
builds).

So, its better to make the mesh functionality disabled/invisible to the
user.

>> Right now, we were trying the disable-mesh-script (''echo 0 > "/sys/class/net/
>> eth0/lbs_mesh"") for our purpose.
>> Now, I am thinking of removing all references to devices of type
>> "DEVICE_TYPE_802_11_OLPC_MESH" from sugar-code. I think that should do it.
>
> Yes, that should do it.
>



- --
Anish
Chris Ball
2012-05-02 04:48:52 UTC
Permalink
Hi,

On Wed, May 02 2012, Ajay Garg wrote:
> Just wish to remove the mesh-icons from Neighborhood-View.

Have you considered just removing the icons directly?

diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/meshbox.py
index 20dc413..0aa8c7f 100644
--- a/src/jarabe/desktop/meshbox.py
+++ b/src/jarabe/desktop/meshbox.py
@@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):

def enable_olpc_mesh(self, mesh_device):
mesh_mgr = OlpcMeshManager(mesh_device)
- self._add_olpc_mesh_icon(mesh_mgr, 1)
- self._add_olpc_mesh_icon(mesh_mgr, 6)
- self._add_olpc_mesh_icon(mesh_mgr, 11)
+ #self._add_olpc_mesh_icon(mesh_mgr, 1)
+ #self._add_olpc_mesh_icon(mesh_mgr, 6)
+ #self._add_olpc_mesh_icon(mesh_mgr, 11)

# the OLPC mesh can be recognised as a "normal" wifi network. remove
# any such normal networks if they have been created

--
Chris Ball <***@laptop.org> <http://printf.net/>
One Laptop Per Child
Ajay Garg
2012-05-02 04:59:45 UTC
Permalink
Yes Chris, that certainly is an option.
But removing the references to the device itself, would clean up both the
model and the view; whereas this (as I think) only removes the view.

Regards,
Ajay

On Wed, May 2, 2012 at 10:18 AM, Chris Ball <***@laptop.org> wrote:

> Hi,
>
> On Wed, May 02 2012, Ajay Garg wrote:
> > Just wish to remove the mesh-icons from Neighborhood-View.
>
> Have you considered just removing the icons directly?
>
> diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/meshbox.py
> index 20dc413..0aa8c7f 100644
> --- a/src/jarabe/desktop/meshbox.py
> +++ b/src/jarabe/desktop/meshbox.py
> @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):
>
> def enable_olpc_mesh(self, mesh_device):
> mesh_mgr = OlpcMeshManager(mesh_device)
> - self._add_olpc_mesh_icon(mesh_mgr, 1)
> - self._add_olpc_mesh_icon(mesh_mgr, 6)
> - self._add_olpc_mesh_icon(mesh_mgr, 11)
> + #self._add_olpc_mesh_icon(mesh_mgr, 1)
> + #self._add_olpc_mesh_icon(mesh_mgr, 6)
> + #self._add_olpc_mesh_icon(mesh_mgr, 11)
>
> # the OLPC mesh can be recognised as a "normal" wifi network.
> remove
> # any such normal networks if they have been created
>
> --
> Chris Ball <***@laptop.org> <http://printf.net/>
> One Laptop Per Child
>
James Cameron
2012-05-02 05:12:18 UTC
Permalink
If all you wish to do is remove the mesh icons from the network
neighbourhood, why would you also want to clean up the model?

On Wed, May 02, 2012 at 10:29:45AM +0530, Ajay Garg wrote:
> Yes Chris, that certainly is an option.
> But removing the references to the device itself, would clean up both the model
> and the view; whereas this (as I think) only removes the view.
>
> Regards,
> Ajay
>
> On Wed, May 2, 2012 at 10:18 AM, Chris Ball <***@laptop.org> wrote:
>
> Hi,
>
> On Wed, May 02 2012, Ajay Garg wrote:
> > Just wish to remove the mesh-icons from Neighborhood-View.
>
> Have you considered just removing the icons directly?
>
> diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/meshbox.py
> index 20dc413..0aa8c7f 100644
> --- a/src/jarabe/desktop/meshbox.py
> +++ b/src/jarabe/desktop/meshbox.py
> @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):
>
> def enable_olpc_mesh(self, mesh_device):
> mesh_mgr = OlpcMeshManager(mesh_device)
> - self._add_olpc_mesh_icon(mesh_mgr, 1)
> - self._add_olpc_mesh_icon(mesh_mgr, 6)
> - self._add_olpc_mesh_icon(mesh_mgr, 11)
> + #self._add_olpc_mesh_icon(mesh_mgr, 1)
> + #self._add_olpc_mesh_icon(mesh_mgr, 6)
> + #self._add_olpc_mesh_icon(mesh_mgr, 11)
>
> # the OLPC mesh can be recognised as a "normal" wifi network.
> remove
> # any such normal networks if they have been created
>
> --
> Chris Ball <***@laptop.org> <http://printf.net/>
> One Laptop Per Child
>
>

--
James Cameron
http://quozl.linux.org.au/
Ajay Garg
2012-05-02 05:17:41 UTC
Permalink
Well.. Hmm.. So that it could mean less (leftover-half-bits) bugs to play
with :P

Regards,
Ajay

On Wed, May 2, 2012 at 10:42 AM, James Cameron <***@laptop.org> wrote:

> If all you wish to do is remove the mesh icons from the network
> neighbourhood, why would you also want to clean up the model?
>
> On Wed, May 02, 2012 at 10:29:45AM +0530, Ajay Garg wrote:
> > Yes Chris, that certainly is an option.
> > But removing the references to the device itself, would clean up both
> the model
> > and the view; whereas this (as I think) only removes the view.
> >
> > Regards,
> > Ajay
> >
> > On Wed, May 2, 2012 at 10:18 AM, Chris Ball <***@laptop.org> wrote:
> >
> > Hi,
> >
> > On Wed, May 02 2012, Ajay Garg wrote:
> > > Just wish to remove the mesh-icons from Neighborhood-View.
> >
> > Have you considered just removing the icons directly?
> >
> > diff --git a/src/jarabe/desktop/meshbox.py
> b/src/jarabe/desktop/meshbox.py
> > index 20dc413..0aa8c7f 100644
> > --- a/src/jarabe/desktop/meshbox.py
> > +++ b/src/jarabe/desktop/meshbox.py
> > @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):
> >
> > def enable_olpc_mesh(self, mesh_device):
> > mesh_mgr = OlpcMeshManager(mesh_device)
> > - self._add_olpc_mesh_icon(mesh_mgr, 1)
> > - self._add_olpc_mesh_icon(mesh_mgr, 6)
> > - self._add_olpc_mesh_icon(mesh_mgr, 11)
> > + #self._add_olpc_mesh_icon(mesh_mgr, 1)
> > + #self._add_olpc_mesh_icon(mesh_mgr, 6)
> > + #self._add_olpc_mesh_icon(mesh_mgr, 11)
> >
> > # the OLPC mesh can be recognised as a "normal" wifi network.
> > remove
> > # any such normal networks if they have been created
> >
> > --
> > Chris Ball <***@laptop.org> <http://printf.net/>
> > One Laptop Per Child
> >
> >
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
James Cameron
2012-05-02 05:25:21 UTC
Permalink
Okay. Take care not to add any when you change all those lines of code.
;-)

On Wed, May 02, 2012 at 10:47:41AM +0530, Ajay Garg wrote:
> Well.. Hmm.. So that it could mean less (leftover-half-bits) bugs to play with
> :P
>
> Regards,
> Ajay
>
> On Wed, May 2, 2012 at 10:42 AM, James Cameron <***@laptop.org> wrote:
>
> If all you wish to do is remove the mesh icons from the network
> neighbourhood, why would you also want to clean up the model?
>
> On Wed, May 02, 2012 at 10:29:45AM +0530, Ajay Garg wrote:
> > Yes Chris, that certainly is an option.
> > But removing the references to the device itself, would clean up both the
> model
> > and the view; whereas this (as I think) only removes the view.
> >
> > Regards,
> > Ajay
> >
> > On Wed, May 2, 2012 at 10:18 AM, Chris Ball <***@laptop.org> wrote:
> >
> > Hi,
> >
> > On Wed, May 02 2012, Ajay Garg wrote:
> > > Just wish to remove the mesh-icons from Neighborhood-View.
> >
> > Have you considered just removing the icons directly?
> >
> > diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/
> meshbox.py
> > index 20dc413..0aa8c7f 100644
> > --- a/src/jarabe/desktop/meshbox.py
> > +++ b/src/jarabe/desktop/meshbox.py
> > @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):
> >
> > def enable_olpc_mesh(self, mesh_device):
> > mesh_mgr = OlpcMeshManager(mesh_device)
> > - self._add_olpc_mesh_icon(mesh_mgr, 1)
> > - self._add_olpc_mesh_icon(mesh_mgr, 6)
> > - self._add_olpc_mesh_icon(mesh_mgr, 11)
> > + #self._add_olpc_mesh_icon(mesh_mgr, 1)
> > + #self._add_olpc_mesh_icon(mesh_mgr, 6)
> > + #self._add_olpc_mesh_icon(mesh_mgr, 11)
> >
> > # the OLPC mesh can be recognised as a "normal" wifi network.
> > remove
> > # any such normal networks if they have been created
> >
> > --
> > Chris Ball <***@laptop.org> <http://printf.net/>
> > One Laptop Per Child
> >
> >
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
>

--
James Cameron
http://quozl.linux.org.au/
Ajay Garg
2012-05-02 05:27:32 UTC
Permalink
Haha.. Okies.. :) :)

Regards,
Ajay

On Wed, May 2, 2012 at 10:55 AM, James Cameron <***@laptop.org> wrote:

> Okay. Take care not to add any when you change all those lines of code.
> ;-)
>
> On Wed, May 02, 2012 at 10:47:41AM +0530, Ajay Garg wrote:
> > Well.. Hmm.. So that it could mean less (leftover-half-bits) bugs to
> play with
> > :P
> >
> > Regards,
> > Ajay
> >
> > On Wed, May 2, 2012 at 10:42 AM, James Cameron <***@laptop.org> wrote:
> >
> > If all you wish to do is remove the mesh icons from the network
> > neighbourhood, why would you also want to clean up the model?
> >
> > On Wed, May 02, 2012 at 10:29:45AM +0530, Ajay Garg wrote:
> > > Yes Chris, that certainly is an option.
> > > But removing the references to the device itself, would clean up
> both the
> > model
> > > and the view; whereas this (as I think) only removes the view.
> > >
> > > Regards,
> > > Ajay
> > >
> > > On Wed, May 2, 2012 at 10:18 AM, Chris Ball <***@laptop.org>
> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, May 02 2012, Ajay Garg wrote:
> > > > Just wish to remove the mesh-icons from Neighborhood-View.
> > >
> > > Have you considered just removing the icons directly?
> > >
> > > diff --git a/src/jarabe/desktop/meshbox.py
> b/src/jarabe/desktop/
> > meshbox.py
> > > index 20dc413..0aa8c7f 100644
> > > --- a/src/jarabe/desktop/meshbox.py
> > > +++ b/src/jarabe/desktop/meshbox.py
> > > @@ -635,9 +635,9 @@ class MeshBox(gtk.VBox):
> > >
> > > def enable_olpc_mesh(self, mesh_device):
> > > mesh_mgr = OlpcMeshManager(mesh_device)
> > > - self._add_olpc_mesh_icon(mesh_mgr, 1)
> > > - self._add_olpc_mesh_icon(mesh_mgr, 6)
> > > - self._add_olpc_mesh_icon(mesh_mgr, 11)
> > > + #self._add_olpc_mesh_icon(mesh_mgr, 1)
> > > + #self._add_olpc_mesh_icon(mesh_mgr, 6)
> > > + #self._add_olpc_mesh_icon(mesh_mgr, 11)
> > >
> > > # the OLPC mesh can be recognised as a "normal" wifi
> network.
> > > remove
> > > # any such normal networks if they have been created
> > >
> > > --
> > > Chris Ball <***@laptop.org> <http://printf.net/>
> > > One Laptop Per Child
> > >
> > >
> >
> > --
> > James Cameron
> > http://quozl.linux.org.au/
> >
> >
>
> --
> James Cameron
> http://quozl.linux.org.au/
>
Paul Fox
2012-05-01 15:06:09 UTC
Permalink
ajay wrote:
> Thanks Paul.
>
> On Tue, May 1, 2012 at 8:03 PM, Paul Fox <***@laptop.org> wrote:
>
> > ajay wrote:
> > > Any ideas please, regarding the two latest queries :) ?
> > >
> > > Regards,
> > > Ajay
> > >
> > > On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg <***@activitycentral.com>
> > wrote:
> > >
> > > > Thanks Martin and Jon for the replies.
> > > >
> > > > On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <
> > ***@gmail.com>wrote:
> > > >
> > > >> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
> > > >> <***@gmail.com> wrote:
> > > >> > Are you guys still using this?
> > > >> >
> > > >>
> > >
> >
> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
> > > resume.d/disable_mesh.sh
> > > >> >
> > > >> > If so, you should remove it IF there is no way to guarantee that it
> > > >> will run
> > > >> > before NM picks up the device. At least it will avoid the crash...
> > > >> >
> > > >> > I would ask in the NM community if there is a better way to
> > disable a
> > > >> > particular device, like banning a device(?).
> > > >>
> > > >> Edit /etc/NetworkManager/NetworkManager.conf
> > > >>
> > > >> Add a line to the [main] section like
> > > >>
> > > >> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's with the
> > > >> mac-address of your mesh device.)
> > > >>
> > > >
> > > >
> > > > This should be a lot cleaner solution.
> > > > However, two queries ::
> > > >
> > > >
> > > > a)
> > > > Doing "ifconfig" on the XO-1, only shows information for "eth0" and
> > "lo"
> > > > (no mesh device listed).
> > > > So, how can the mac address for the mesh device be found?
> >
> > it's the same as that for eth0.
> >
>
> Does that mean, that banning eth0-mac-address prevent the loading of
> wifi-hardware-device as well (in obvious addition to mesh) ?
> This seems very pricky.

i don't know. i'm unfamiliar with NM config. it doesn't sound too
hard to try.

paul

>
>
>
>
>
> >
> > > > b)
> > > > Are mac address for XO-1s, EXACTLY same, for every XO-1 on this
> > planet?
> >
> > of course not. how would they tell one another apart?
> >
>
> Alright.
> But my first doubt (same mac address for mesh-hardware and wifi-hardware)
> has put me in topspin :~
>
>
>
> Regards,
> Ajay
>
>
>
>
>
> >
> > paul
> >
> > > >
> > > >
> > > > Looking forward to a reply.
> > > >
> > > >
> > > >
> > > > Thanks and Regards,
> > > > Ajay
> > > >
> > > >
> > > >
> > > >>
> > > >> This does not stop NM from managing your device, but does stop it
> > from
> > > >> auto-connecting the device. You would still be able to go into NM
> > and
> > > >> manually enable the mesh network. If you want NM to completely
> > leave
> > > >> the device alone you can go one more step.
> > > >>
> > > >> Also in /etc/NetworkManager/NetworkManager.conf
> > > >>
> > > >> change the plugins line to
> > > >>
> > > >> plugins=ifcfg-rh,keyfile
> > > >>
> > > >> Then add a section that looks like this.
> > > >>
> > > >> [keyfile]
> > > >> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac
> > address
> > > >> of the device you want to ignore)
> > > >>
> > > >>
> > > >> Hope that helps, let me know if you have further questions.
> > > >>
> > > >> -Jon
> > > >>
> > > >
> > > >
> > > part 2 text/plain 129
> > > _______________________________________________
> > > Devel mailing list
> > > ***@lists.laptop.org
> > > http://lists.laptop.org/listinfo/devel
> >
> > =---------------------
> > paul fox, ***@laptop.org
> >

=---------------------
paul fox, ***@laptop.org
Ajay Garg
2012-05-01 15:20:02 UTC
Permalink
Thanks Paul.

I will give it a try myself.

Just one last question ::
I suppose that 'echo 0 > "/sys/class/net/eth0/lbs_mesh"' is a hack that is
olpc-customised. So, I will be really grateful if you could point me to
some docs (a wiki page may be), that provide information as to how this
hack affects, and is affected.


Thanks for your help.

Regards,
Ajay

On Tue, May 1, 2012 at 8:36 PM, Paul Fox <***@laptop.org> wrote:

> ajay wrote:
> > Thanks Paul.
> >
> > On Tue, May 1, 2012 at 8:03 PM, Paul Fox <***@laptop.org> wrote:
> >
> > > ajay wrote:
> > > > Any ideas please, regarding the two latest queries :) ?
> > > >
> > > > Regards,
> > > > Ajay
> > > >
> > > > On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg <
> ***@activitycentral.com>
> > > wrote:
> > > >
> > > > > Thanks Martin and Jon for the replies.
> > > > >
> > > > > On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <
> > > ***@gmail.com>wrote:
> > > > >
> > > > >> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
> > > > >> <***@gmail.com> wrote:
> > > > >> > Are you guys still using this?
> > > > >> >
> > > > >>
> > > >
> > >
> >
> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
> > > > resume.d/disable_mesh.sh
> > > > >> >
> > > > >> > If so, you should remove it IF there is no way to guarantee
> that it
> > > > >> will run
> > > > >> > before NM picks up the device. At least it will avoid the
> crash...
> > > > >> >
> > > > >> > I would ask in the NM community if there is a better way to
> > > disable a
> > > > >> > particular device, like banning a device(?).
> > > > >>
> > > > >> Edit /etc/NetworkManager/NetworkManager.conf
> > > > >>
> > > > >> Add a line to the [main] section like
> > > > >>
> > > > >> no-auto-default=xx:xx:xx:xx:xx (obviously replacing the x's
> with the
> > > > >> mac-address of your mesh device.)
> > > > >>
> > > > >
> > > > >
> > > > > This should be a lot cleaner solution.
> > > > > However, two queries ::
> > > > >
> > > > >
> > > > > a)
> > > > > Doing "ifconfig" on the XO-1, only shows information for "eth0"
> and
> > > "lo"
> > > > > (no mesh device listed).
> > > > > So, how can the mac address for the mesh device be found?
> > >
> > > it's the same as that for eth0.
> > >
> >
> > Does that mean, that banning eth0-mac-address prevent the loading of
> > wifi-hardware-device as well (in obvious addition to mesh) ?
> > This seems very pricky.
>
> i don't know. i'm unfamiliar with NM config. it doesn't sound too
> hard to try.
>
> paul
>
> >
> >
> >
> >
> >
> > >
> > > > > b)
> > > > > Are mac address for XO-1s, EXACTLY same, for every XO-1 on this
> > > planet?
> > >
> > > of course not. how would they tell one another apart?
> > >
> >
> > Alright.
> > But my first doubt (same mac address for mesh-hardware and
> wifi-hardware)
> > has put me in topspin :~
> >
> >
> >
> > Regards,
> > Ajay
> >
> >
> >
> >
> >
> > >
> > > paul
> > >
> > > > >
> > > > >
> > > > > Looking forward to a reply.
> > > > >
> > > > >
> > > > >
> > > > > Thanks and Regards,
> > > > > Ajay
> > > > >
> > > > >
> > > > >
> > > > >>
> > > > >> This does not stop NM from managing your device, but does stop
> it
> > > from
> > > > >> auto-connecting the device. You would still be able to go into
> NM
> > > and
> > > > >> manually enable the mesh network. If you want NM to completely
> > > leave
> > > > >> the device alone you can go one more step.
> > > > >>
> > > > >> Also in /etc/NetworkManager/NetworkManager.conf
> > > > >>
> > > > >> change the plugins line to
> > > > >>
> > > > >> plugins=ifcfg-rh,keyfile
> > > > >>
> > > > >> Then add a section that looks like this.
> > > > >>
> > > > >> [keyfile]
> > > > >> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's are the mac
> > > address
> > > > >> of the device you want to ignore)
> > > > >>
> > > > >>
> > > > >> Hope that helps, let me know if you have further questions.
> > > > >>
> > > > >> -Jon
> > > > >>
> > > > >
> > > > >
> > > > part 2 text/plain 129
> > > > _______________________________________________
> > > > Devel mailing list
> > > > ***@lists.laptop.org
> > > > http://lists.laptop.org/listinfo/devel
> > >
> > > =---------------------
> > > paul fox, ***@laptop.org
> > >
>
> =---------------------
> paul fox, ***@laptop.org
>
Jerry Vonau
2012-05-01 15:51:48 UTC
Permalink
On Tue, 2012-05-01 at 20:50 +0530, Ajay Garg wrote:
> Thanks Paul.
>
> I will give it a try myself.
>
> Just one last question ::
> I suppose that 'echo 0 > "/sys/class/net/eth0/lbs_mesh"' is a hack
> that is olpc-customised. So, I will be really grateful if you could
> point me to some docs (a wiki page may be), that provide information
> as to how this hack affects, and is affected.
>
>

Ajay:

http://wiki.laptop.org/go/Mesh_Network_Details
http://wiki.laptop.org/go/Wireless_Driver_README

Are installing the dextrose-platform rpm?
http://download.sugarlabs.org/dextrose/testing/dx3/rpms/source/dextrose-platform-2-2.fc14.src.rpm

Jerry


> Thanks for your help.
>
> Regards,
> Ajay
>
> On Tue, May 1, 2012 at 8:36 PM, Paul Fox <***@laptop.org> wrote:
> ajay wrote:
> > Thanks Paul.
> >
> > On Tue, May 1, 2012 at 8:03 PM, Paul Fox <***@laptop.org>
> wrote:
> >
> > > ajay wrote:
> > > > Any ideas please, regarding the two latest
> queries :) ?
> > > >
> > > > Regards,
> > > > Ajay
> > > >
> > > > On Mon, Apr 30, 2012 at 1:00 PM, Ajay Garg
> <***@activitycentral.com>
> > > wrote:
> > > >
> > > > > Thanks Martin and Jon for the replies.
> > > > >
> > > > > On Sun, Apr 29, 2012 at 3:04 PM, Jon Nettleton <
> > > ***@gmail.com>wrote:
> > > > >
> > > > >> On Sun, Apr 29, 2012 at 10:04 AM, Martin Abente
> > > > >> <***@gmail.com> wrote:
> > > > >> > Are you guys still using this?
> > > > >> >
> > > > >>
> > > >
> > >
> >
> http://git.sugarlabs.org/dextrose-platform/mainline/blobs/master/etc/powerd/post
> > > > resume.d/disable_mesh.sh
> > > > >> >
> > > > >> > If so, you should remove it IF there is no way to
> guarantee that it
> > > > >> will run
> > > > >> > before NM picks up the device. At least it will
> avoid the crash...
> > > > >> >
> > > > >> > I would ask in the NM community if there is a
> better way to
> > > disable a
> > > > >> > particular device, like banning a device(?).
> > > > >>
> > > > >> Edit /etc/NetworkManager/NetworkManager.conf
> > > > >>
> > > > >> Add a line to the [main] section like
> > > > >>
> > > > >> no-auto-default=xx:xx:xx:xx:xx (obviously replacing
> the x's with the
> > > > >> mac-address of your mesh device.)
> > > > >>
> > > > >
> > > > >
> > > > > This should be a lot cleaner solution.
> > > > > However, two queries ::
> > > > >
> > > > >
> > > > > a)
> > > > > Doing "ifconfig" on the XO-1, only shows information
> for "eth0" and
> > > "lo"
> > > > > (no mesh device listed).
> > > > > So, how can the mac address for the mesh device be
> found?
> > >
> > > it's the same as that for eth0.
> > >
> >
> > Does that mean, that banning eth0-mac-address prevent the
> loading of
> > wifi-hardware-device as well (in obvious addition to
> mesh) ?
> > This seems very pricky.
>
>
> i don't know. i'm unfamiliar with NM config. it doesn't
> sound too
> hard to try.
>
> paul
>
> >
> >
> >
> >
> >
> > >
> > > > > b)
> > > > > Are mac address for XO-1s, EXACTLY same, for every
> XO-1 on this
> > > planet?
> > >
> > > of course not. how would they tell one another apart?
> > >
> >
> > Alright.
> > But my first doubt (same mac address for mesh-hardware and
> wifi-hardware)
> > has put me in topspin :~
> >
> >
> >
> > Regards,
> > Ajay
> >
> >
> >
> >
> >
> > >
> > > paul
> > >
> > > > >
> > > > >
> > > > > Looking forward to a reply.
> > > > >
> > > > >
> > > > >
> > > > > Thanks and Regards,
> > > > > Ajay
> > > > >
> > > > >
> > > > >
> > > > >>
> > > > >> This does not stop NM from managing your device,
> but does stop it
> > > from
> > > > >> auto-connecting the device. You would still be
> able to go into NM
> > > and
> > > > >> manually enable the mesh network. If you want NM
> to completely
> > > leave
> > > > >> the device alone you can go one more step.
> > > > >>
> > > > >> Also in /etc/NetworkManager/NetworkManager.conf
> > > > >>
> > > > >> change the plugins line to
> > > > >>
> > > > >> plugins=ifcfg-rh,keyfile
> > > > >>
> > > > >> Then add a section that looks like this.
> > > > >>
> > > > >> [keyfile]
> > > > >> unmanaged-devices=mac:xx:xx:xx:xx:xx:xx (Where X's
> are the mac
> > > address
> > > > >> of the device you want to ignore)
> > > > >>
> > > > >>
> > > > >> Hope that helps, let me know if you have further
> questions.
> > > > >>
> > > > >> -Jon
> > > > >>
> > > > >
> > > > >
> > > > part 2 text/plain 129
> > > > _______________________________________________
> > > > Devel mailing list
> > > > ***@lists.laptop.org
> > > > http://lists.laptop.org/listinfo/devel
> > >
> > > =---------------------
> > > paul fox, ***@laptop.org
> > >
>
>
> =---------------------
> paul fox, ***@laptop.org
>
> _______________________________________________
> Devel mailing list
> ***@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
Loading...