'ifconfig eth0' can't work immediately on android mx53 after boot up

Is that really what happened here? It looks like it did get the ip address, just not the one it requested (from a previous run perhaps?)

Also, are we sure this just happens on mx53? I think I've seen this on other boards and assumed it was either that, or the dhcp server was having issues again.

> Is that really what happened here? It looks like it did get the ip address, just not the one it requested (from a previous run perhaps?)
The network doesn't bring up when getting IP by 'ifconfig', then there is a network up message:
 [ 22.512335] eth0: Freescale FEC PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=1:00, irq=-1)
[ 24.508410] PHY: 1:00 - Link is Up - 100/Full

> Also, are we sure this just happens on mx53? I think I've seen this on other boards and assumed it was either that, or the dhcp server was having issues again.
I've added a section of code to wait until network up by wait_network_up(), so it could be applied to all boards.

On 15 November 2011 10:42, Spring Zhang <email address hidden> wrote:

> > Is that really what happened here? It looks like it did get the ip
> address, just not the one it requested (from a previous run perhaps?)
> The network doesn't bring up when getting IP by 'ifconfig', then there is
> a network up message:
> [ 22.512335] eth0: Freescale FEC PHY driver [SMSC LAN8710/LAN8720]
> (mii_bus:phy_addr=1:00, irq=-1)
> [ 24.508410] PHY: 1:00 - Link is Up - 100/Full
>
> > Also, are we sure this just happens on mx53? I think I've seen this on
> other boards and assumed it was either that, or the dhcp server was having
> issues again.
> I've added a section of code to wait until network up by
> wait_network_up(), so it could be applied to all boards.
>
> actually, the method _get_default_nic_ip_by_ifconfig is only called in
method "get_default_nic_ip",
if get_default_nic_ip can't get the IP address at the first time, it will
try to execute "netcfg %s dhcp" to get a dhcp IP address,
and then get the IP address again.

But if the first time failed, it will catch exception and run
[logging.exception("_get_default_nic_ip_by_ifconfig failed")],
and print out the exception information.
although this will not affect the result, it make a little confusion.

Like this:
The first time to get ip address

>root@linaro: ifconfig eth0
>eth0: Cannot assign requested address
>root@linaro: [ 22.512335] eth0: Freescale FEC PHY driver [SMSC
LAN8710/LAN8720] (mii_bus:phy_addr=1:00, irq=-1)
>[ 24.508410] PHY: 1:00 - Link is Up - 100/Full
The second time to get ip address

>root@linaro: ifconfig eth0
>eth0: ip 10.192.244.14 mask 255.255.255.0 flags [up broadcast running
multicast]
>root@linaro: (user:root) disconnected
The reason why try to get IP first is that sometimes the image will booted
up with IP has been set, under case like this, there is no need to get DHCP
IP address again.

IMO, here just replace "logging.exception" with "logging.info" is OK.
Adding wait_network_up will still have the same problem I guess.

Thanks,
Yongqin Liu

'netcfg eth0 dhcp' can work on mx53 now, I don't know why. The second 'ifconfig eth0' is inputed by me from the conmux console directly, if 'netcfg eth0 dhcp' works, I won't meet the error, and it mentioned to add some actions on such SoC which fails to get IP by dhcp.

> 'netcfg eth0 dhcp' can work on mx53 now, I don't know why.
Sorry, type error, I mean it CAN't.

On 15 November 2011 16:31, Spring Zhang <email address hidden> wrote:

> > 'netcfg eth0 dhcp' can work on mx53 now, I don't know why.
> Sorry, type error, I mean it CAN't.

Then how can the image get IP address?
or its default interface is not eth0?

>
> Then how can the image get IP address?
> or its default interface is not eth0?

conversation from IRC log:
<liuyq> but how can it get IP, just wait until it get a IP?
<springz> eth0 will auto up after some seconds just after 'ifconfig
eth0', then it execute netcfg
<springz> if it wait 5 seconds, it will get ip by first 'ifconfig eth0'
<liuyq> is there some settings like /etc/network/interfaces?
<springz> no, there is some delay for network interface up, I don't
know why it's so slow
<springz> but I've added wait_network_up in it, it will wait 2 mins

include Freescale LT in the loop. Adding a timeout seems a work around.

Workaround for timeout is added in LAVA side, no need in LT, the image generates the timeout.

Doesn't look like i.mx53 LT kernel related, I'll mark it as 'Invalid' first until this will need fix within the kernel. Thanks.