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