Re: Re: [Dextrose] WiFi vs Suspend

2010-08-25 Thread forster
 If you spot this bug again, could you please:
 
  * check whether eth0 is still visible with ifconfig -a
 
  * check whether the Marvell 8xxx is still visible with lsusb
 
  * dmesg dmesg.out and attach it to the bug. Dextrose enables
libertas debug in /etc/rc.local to help diagnose this bug.

Sorry do not understand how to find dmesg
rc.local points to sys/module/libertas/parameters/libertas_debug = 156039

In good state, before suspend:
[o...@xo-14-6c-6c ~]$ ifconfig -a
eth0  Link encap:Ethernet  HWaddr 00:17:C4:14:6C:6C  
  inet addr:10.1.1.2  Bcast:10.255.255.255  Mask:255.0.0.0
  inet6 addr: fe80::217:c4ff:fe14:6c6c/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:806 errors:0 dropped:0 overruns:0 frame:0
  TX packets:781 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:748218 (730.6 KiB)  TX bytes:99791 (97.4 KiB)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:26 errors:0 dropped:0 overruns:0 frame:0
  TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:2872 (2.8 KiB)  TX bytes:2872 (2.8 KiB)

[o...@xo-14-6c-6c ~]$ lsusb
Bus 002 Device 002: ID 1286:2001 Marvell Semiconductor, Inc. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


In the locked up state, the first few minutes of resume after suspend:
[o...@xo-14-6c-6c ~]$ lsusb
Bus 002 Device 002: ID 1286:2001 Marvell Semiconductor, Inc. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
[o...@xo-14-6c-6c ~]$ ifconfig -a
eth0  Link encap:Ethernet  HWaddr 00:17:C4:14:6C:6C  
  inet addr:10.1.1.2  Bcast:10.255.255.255  Mask:255.0.0.0
  inet6 addr: fe80::217:c4ff:fe14:6c6c/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:826 errors:0 dropped:0 overruns:0 frame:0
  TX packets:821 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:750021 (732.4 KiB)  TX bytes:102253 (99.8 KiB)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:38 errors:0 dropped:0 overruns:0 frame:0
  TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:4168 (4.0 KiB)  TX bytes:4168 (4.0 KiB)

[o...@xo-14-6c-6c ~]$
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Re: [Dextrose] WiFi vs Suspend

2010-08-25 Thread forster

  * dmesg dmesg.out and attach it to the bug. Dextrose enables
libertas debug in /etc/rc.local to help diagnose this bug.

took me 10 minutes after it came good to work out dmesg so this is a bit later 
than the event:

[0.00] Linux version 2.6.31_xo1-20100701.1605.1.olpc.a8f1b26 
(c...@bob.laptop.org) (gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC) ) #1 
PREEMPT Thu Jul 1 16:08:10 EDT 2010
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   NSC Geode by NSC
[0.00]   Cyrix CyrixInstead
[0.00]   Centaur CentaurHauls
[0.00]   Transmeta GenuineTMx86
[0.00]   Transmeta TransmetaCPU
[0.00]   UMC UMC UMC UMC
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e801:  - 0009f000 (usable)
[0.00]  BIOS-e801: 0010 - 0ded5400 (usable)
[0.00] DMI 2.1 present.
[0.00] last_pfn = 0xded5 max_arch_pfn = 0x10
[0.00] initial memory mapped : 0 - 00c0
[0.00] init_memory_mapping: -0ded5000
[0.00]  00 - 40 page 4k
[0.00]  40 - 000dc0 page 2M
[0.00]  000dc0 - 000ded5000 page 4k
[0.00] kernel direct mapping tables up to ded5000 @ 7000-c000
[0.00] RAMDISK: 0ded5400 - 0ec0
[0.00] Allocated new RAMDISK: 007ca000 - 014f4c00
[0.00] Move RAMDISK from 0ded5400 - 0ebf to 
007ca000 - 014f4bff
[0.00] 222MB LOWMEM available.
[0.00]   mapped low ram: 0 - 0ded5000
[0.00]   low ram: 0 - 0ded5000
[0.00]   node 0 low ram:  - 0ded5000
[0.00]   node 0 bootmap 1000 - 2bdc
[0.00] (7 early reservations) == bootmem [00 - 000ded5000]
[0.00]   #0 [00 - 001000]   BIOS data page == [00 
- 001000]
[0.00]   #1 [40 - 7c53a0]TEXT DATA BSS == [40 
- 7c53a0]
[0.00]   #2 [09f000 - 10]BIOS reserved == [09f000 
- 10]
[0.00]   #3 [7c6000 - 7c90cc]  BRK == [7c6000 
- 7c90cc]
[0.00]   #4 [007000 - 008000]  PGTABLE == [007000 
- 008000]
[0.00]   #5 [7ca000 - 00014f4c00]  NEW RAMDISK == [7ca000 
- 00014f4c00]
[0.00]   #6 [001000 - 003000]  BOOTMAP == [001000 
- 003000]
[0.00] Zone PFN ranges:
[0.00]   DMA  0x - 0x1000
[0.00]   Normal   0x1000 - 0xded5
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[2] active PFN ranges
[0.00] 0: 0x - 0x009f
[0.00] 0: 0x0100 - 0xded5
[0.00] On node 0 totalpages: 56948
[0.00] free_area_init_node: node 0, pgdat c07458ac, node_mem_map 
c14f5000
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3967 pages, LIFO batch:0
[0.00]   Normal zone: 414 pages used for memmap
[0.00]   Normal zone: 52535 pages, LIFO batch:15
[0.00] Allocating PCI resources starting at ded5400 (gap: 
ded5400:f212ac00)
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 56502
[0.00] Kernel command line: no_console_suspend selinux=0 ro 
root=/dev/mtdblock0 rootfstype=jffs2 console=ttyS0,115200 console=tty0 
fbcon=font:SUN12x22
[0.00] PID hash table entries: 1024 (order: 10, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Initializing CPU#0
[0.00] Memory: 208244k/228180k available (2570k kernel code, 19360k 
reserved, 802k data, 220k init, 0k highmem)
[0.00] virtual kernel memory layout:
[0.00] fixmap  : 0xfffe6000 - 0xf000   ( 100 kB)
[0.00] vmalloc : 0xce6d5000 - 0xfffe4000   ( 793 MB)
[0.00] lowmem  : 0xc000 - 0xcded5000   ( 222 MB)
[0.00]   .init : 0xc074c000 - 0xc0783000   ( 220 kB)
[0.00]   .data : 0xc068288d - 0xc074b48c   ( 802 kB)
[0.00]   .text : 0xc040 - 0xc068288d   (2570 kB)
[0.00] Checking if this processor honours the WP bit even in supervisor 
mode...Ok.
[0.00] NR_IRQS:16
[0.00] CPU 0 irqstacks, hard=c071a000 soft=c071b000
[0.00] Fast TSC calibration using PIT
[0.00] Detected 430.981 MHz processor.
[0.000321] Console: colour EGA 80x25
[0.000340] console [tty0] enabled
[0.004358] console [ttyS0] enabled
[0.010020] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 861.96 BogoMIPS (lpj=4309810)
[0.020179] Security Framework initialized
[0.024421] Mount-cache hash table entries: 512
[0.030159] CPU: 

Re: Re: Re: [Dextrose] WiFi vs Suspend

2010-08-25 Thread forster
attached file dmesg___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Dextrose] WiFi vs Suspend

2010-08-25 Thread Paul Fox
tony -- thanks for this.  if you could, please open a trac ticket (bug
report) at http://dev.laptop.org to describe this issue.  the next
time it occurs, in order to more simply gather most of the information
bernie asked for, plus a little more that may be useful, please run
the command olpc-log from a Terminal window.  this will create a
file called logs.serial_no.timestamp.tar.bz2 in your current
directory.  please attach that file to the trac ticket.  in fact,
please run the command twice -- once during the locked up period,
and again after, and attach both files.  possibly overkill, but might
be useful.

(the olpc-log command takes an fairly long time to run, but it collects
lots of information.)

paul

fors...@ozonline.com.au wrote:
  Bernie
  
  Sorry, on closer inspection its not locked up, it just looks like its locked 
  up 
  because it is doing something else for a long time.
  
  Can be replicated 100%. Shut the lid for a while, 5 minutes is not long 
  enough 
  1.5 hours is. Resume from sleep. The Wifi shows it is connected at 100% 
  signal 
  (signal is not 100%). There is no internet access. There is no response to 
  Disconnect. Previously I had given up and restarted but if you wait 3 
  minutes 
  or so it disconnects and then works normally.
  
  Tony
  
   [cc += olpc-devel]
   
   El Wed, 25-08-2010 a las 11:05 +1000, fors...@ozonline.com.au escribió:
OS373pyg
Wifi is locked up after resume from sleep, must restart.
I presume this bug is being tracked at dev.laptop.org/ in one of the 4 
  tickets below
   
  http://dev.laptop.org/ticket/10232  WiFi dies on suspended XO-1,os300
  http://dev.laptop.org/ticket/10092  Networking broken over 
suspend/resume 
  on os13 for XO-1
  http://dev.laptop.org/ticket/9960   wake-on-WLAN doesn't always work\ 
  (duplicate)
  http://dev.laptop.org/ticket/9967   ibertas suspend fails on XO-1 
(fixed)
   
   There are a number of unsolved bugs in the libertas kernel driver or in
   its fantastically proprietary firmare. If you turned on automatic power
   management on an XO-1, you might be seeing this other one:
   
http://dev.laptop.org/ticket/10195
   
   
   In short, very rarely the libertas usb8xxx disappears from the USB bus
   when it receives certain commands from the driver. Suspend/resume are
   known to trigger quite frequently and the mesh also seems to cause it
   once or twice per day in a classroom of 30 students.
   
   Because time for debugging was running out, in the latest beta builds I
   had to disable both mesh support and automatic power management in the
   attempt to get rid of this bug. After one week of testing, the problem
   was not reported any more.
   
   If you spot this bug again, could you please:
   
* check whether eth0 is still visible with ifconfig -a
   
* check whether the Marvell 8xxx is still visible with lsusb
   
* dmesg dmesg.out and attach it to the bug. Dextrose enables
  libertas debug in /etc/rc.local to help diagnose this bug.
   
   
   This never ending saga brings me back to an exasperated email that David
   Woodhouse wrote about 3 years ago, after spending many days in
   unfruitful debugging, in which he warned that access to the source code
   of the firmware was essential in order to nail down all the obscure
   Libertas bugs.
   
   -- 
  // Bernie Innocenti - http://codewiz.org/
\X/  Sugar Labs   - http://sugarlabs.org/
   
   
   _
   This mail has been virus scanned by Australia On Line
   see http://www.australiaonline.net.au/mailscanning
  
  part 2 text/plain 129
  ___
  Devel mailing list
  Devel@lists.laptop.org
  http://lists.laptop.org/listinfo/devel

=-
 paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Re: [Dextrose] WiFi vs Suspend

2010-08-25 Thread Bernie Innocenti
El Wed, 25-08-2010 a las 20:45 +1000, fors...@ozonline.com.au escribió:
   * dmesg dmesg.out and attach it to the bug. Dextrose enables
 libertas debug in /etc/rc.local to help diagnose this bug.
 
 took me 10 minutes after it came good to work out dmesg so this is a bit 
 later than the event:

That's odd, debug does not seem to be on.

Is this really os373py? What's in /etc/rc.local?

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

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


Re: Re: Re: [Dextrose] WiFi vs Suspend

2010-08-25 Thread forster

 That's odd, debug does not seem to be on.
 
 Is this really os373py? What's in /etc/rc.local?

Still getting my head round this stuff. I presume [xx.xx] is the timestamp in 
seconds. The log activity dmesg captures the first 16 seconds after startup, 
dmesg in terminal shows [xx.xx]=1 aprox. I emailed the dmesg terminal 
output as an attachment. This discussion may be taking up too much bandwidth on 
the list, maybe opened as a bug on Trac? Existing bug or new? Laptop or 
Sugarlabs? Component?

Tony
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Dextrose] WiFi vs Suspend

2010-08-24 Thread Bernie Innocenti
[cc += olpc-devel]

El Wed, 25-08-2010 a las 11:05 +1000, fors...@ozonline.com.au escribió:
 OS373pyg
 Wifi is locked up after resume from sleep, must restart.
 I presume this bug is being tracked at dev.laptop.org/ in one of the 4 
 tickets below

   http://dev.laptop.org/ticket/10232  WiFi dies on suspended XO-1,os300
   http://dev.laptop.org/ticket/10092  Networking broken over suspend/resume 
 on os13 for XO-1
   http://dev.laptop.org/ticket/9960   wake-on-WLAN doesn't always work\ 
 (duplicate)
   http://dev.laptop.org/ticket/9967   ibertas suspend fails on XO-1 (fixed)

There are a number of unsolved bugs in the libertas kernel driver or in
its fantastically proprietary firmare. If you turned on automatic power
management on an XO-1, you might be seeing this other one:

 http://dev.laptop.org/ticket/10195


In short, very rarely the libertas usb8xxx disappears from the USB bus
when it receives certain commands from the driver. Suspend/resume are
known to trigger quite frequently and the mesh also seems to cause it
once or twice per day in a classroom of 30 students.

Because time for debugging was running out, in the latest beta builds I
had to disable both mesh support and automatic power management in the
attempt to get rid of this bug. After one week of testing, the problem
was not reported any more.

If you spot this bug again, could you please:

 * check whether eth0 is still visible with ifconfig -a

 * check whether the Marvell 8xxx is still visible with lsusb

 * dmesg dmesg.out and attach it to the bug. Dextrose enables
   libertas debug in /etc/rc.local to help diagnose this bug.


This never ending saga brings me back to an exasperated email that David
Woodhouse wrote about 3 years ago, after spending many days in
unfruitful debugging, in which he warned that access to the source code
of the firmware was essential in order to nail down all the obscure
Libertas bugs.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

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


Re: Re: [Dextrose] WiFi vs Suspend

2010-08-24 Thread forster
Bernie

Sorry, on closer inspection its not locked up, it just looks like its locked up 
because it is doing something else for a long time.

Can be replicated 100%. Shut the lid for a while, 5 minutes is not long enough 
1.5 hours is. Resume from sleep. The Wifi shows it is connected at 100% signal 
(signal is not 100%). There is no internet access. There is no response to 
Disconnect. Previously I had given up and restarted but if you wait 3 minutes 
or so it disconnects and then works normally.

Tony

 [cc += olpc-devel]
 
 El Wed, 25-08-2010 a las 11:05 +1000, fors...@ozonline.com.au escribió:
  OS373pyg
  Wifi is locked up after resume from sleep, must restart.
  I presume this bug is being tracked at dev.laptop.org/ in one of the 4 
  tickets below
 
http://dev.laptop.org/ticket/10232  WiFi dies on suspended XO-1,os300
http://dev.laptop.org/ticket/10092  Networking broken over suspend/resume 
  on os13 for XO-1
http://dev.laptop.org/ticket/9960   wake-on-WLAN doesn't always work\ 
  (duplicate)
http://dev.laptop.org/ticket/9967   ibertas suspend fails on XO-1 (fixed)
 
 There are a number of unsolved bugs in the libertas kernel driver or in
 its fantastically proprietary firmare. If you turned on automatic power
 management on an XO-1, you might be seeing this other one:
 
  http://dev.laptop.org/ticket/10195
 
 
 In short, very rarely the libertas usb8xxx disappears from the USB bus
 when it receives certain commands from the driver. Suspend/resume are
 known to trigger quite frequently and the mesh also seems to cause it
 once or twice per day in a classroom of 30 students.
 
 Because time for debugging was running out, in the latest beta builds I
 had to disable both mesh support and automatic power management in the
 attempt to get rid of this bug. After one week of testing, the problem
 was not reported any more.
 
 If you spot this bug again, could you please:
 
  * check whether eth0 is still visible with ifconfig -a
 
  * check whether the Marvell 8xxx is still visible with lsusb
 
  * dmesg dmesg.out and attach it to the bug. Dextrose enables
libertas debug in /etc/rc.local to help diagnose this bug.
 
 
 This never ending saga brings me back to an exasperated email that David
 Woodhouse wrote about 3 years ago, after spending many days in
 unfruitful debugging, in which he warned that access to the source code
 of the firmware was essential in order to nail down all the obscure
 Libertas bugs.
 
 -- 
// Bernie Innocenti - http://codewiz.org/
  \X/  Sugar Labs   - http://sugarlabs.org/
 
 
 _
 This mail has been virus scanned by Australia On Line
 see http://www.australiaonline.net.au/mailscanning

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