WLAN: known issues and how to help - uptime test - more results

Philip Rhoades phil at pricom.com.au
Mon Feb 9 07:22:15 CET 2009


Werner,


Werner Almesberger wrote:
> Philip Rhoades wrote:
>> NAND read: device 0 offset 0x80000, size 0x200000
> 
> Funny. It didn't take the increase. But after the reboot it did, so
> we have a happy ending ;-)
> 
>> However if I use reboot, the FR starts up and I can connect to  
>> 192.168.0.202 via USB again.
> 
> Perfect !


I was not convinced it was doing the right thing so I repeated the 
exercise and saw:

   NAND read: device 0 offset 0x80000, size 0x300000

before typing "boot" but then I got (it is hard to read):

   regulator : Unable to get requested regulator
   SO_3V3sc2440-sdi SO_3V3sc2440-sdi : Regulator for SO_3V3 unavailable
   Cannot create link /etc/mtab~
   Perhaps there is a stale lock file?

and the last two lines just keep repeating . .


>> I have then rebooted but usb0 remains at 192.168.0.202
> 
> Unless you changed the init script, a reboot will return usb0 to its
> default settings. If you want a different address, you can edit
> /sbin/init. It's a shell script.
> 
>> and the USB link does not remain up long enough for me to  
>> look at things (maybe because of conflict with my 192.169.0.* LAN?) -  
> 
> Could it be that USB locked up for some reason ? I'm seeing this
> from time to time. Just unplugging and reconnecting USB and then
> ssh'ing in again usually solves this. (The usb0 IP address is
> preserved.)
> 
>> can you do a rootfs that uses DHCP to set up eth0 so I don't need to  
>> mess around with usb0?
> 
> Hmm, I don't understand ... how would using DHCP for eth0 help with
> usb0 ?


I meant I wanted to NOT use the USB connection at all . . just go 
straight to wireless.


> In fact, part of the purpose of this rootfs is to keep things
> as manual as possible, so that funny interactions of system services
> can be debugged one step at a time.


OK.


> Anyway, I think you could just try to use your normal rootfs. If
> the problem is the assertion failure, then this will be the easiest
> way to reproduce it and we won't need any of the debugging
> capabilities of the wlan-trial rootfs.


It looks like there is still a boot problem . .


>> I presume it also uses memory that would normally be available for  
>> something else?
> 
> Nope, it just reads 3 MB instead of 2 MB from the 8 MB kernel
> partition. As far as RAM size is concerned, a "small" kernel will
> only use what it needs and happily ignore all the rest that u-boot
> has loaded from NAND.


OK.


>> OK but would it be a good idea for normal use?  Faster?
> 
> Faster, leaner, meaner, cleaner ;-) However, it can also be a bit
> of a learning experience. So perhaps it's better to change one
> thing at a time to avoid confusion.


Right.

Regards,

Phil.
-- 
Philip Rhoades

GPO Box 3411
Sydney NSW	2001
Australia
E-mail:  phil at pricom.com.au



More information about the devel mailing list