• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: [1]
1  Hardware and U-Boot firmware / Hardware / Re: Very persistent eth0 on: October 07, 2009, 08:18:57 PM
To answer myself - no, it's not a bug in the driver, udev actually has a rule that causes ifup to run (/lib/udev/rules.d/85-ifupdown.rules). After commenting the ADD rule there, everything works as expected. And there's https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/366967 to discuss that.
2  Hardware and U-Boot firmware / Hardware / Very persistent eth0 on: October 07, 2009, 06:43:04 PM
I arrived at very weird conclusion, but let me start from the beginning.
I'm running sheevaplug with ubuntu 9.04, with uboot updated to use kernel on SD.
Linux vishnu #1 PREEMPT Mon Oct 5 15:46:04 MDT 2009 armv5tel GNU/Linux

I wanted to have a smbfs share mounted at boot. After adding to fstab, I found that it doesn't get mounted. At first I was expecting a problem with /etc/network/if-up.d/mountnfs script, but soon I found that it's ONLY during boot that things are not working. If I ran /etc/init.d/networking restart or ifdown eth0; ifup eth0, the share was mounted properly.

I've tracked it down to /etc/init.d/networking calling ifup, which in turn was NOT calling proper scripts in if-up.d. Few straces later, I found that by the time /etc/init.d/networking is ran, the eth0 is... already up and configured.

What the hell?

I've started to track the state of the interfaces at different stages of boot. I've made a very small script, that would just run 'ifconfig' (without -a) to show what interfaces are up at given stage. Then I added this script to other scripts in rcS.d. I've narrowed it down to udev - the interface is up and configured after udev finishes. I don't expect udev does something wrong, it's just a matter of udev initializing the mv643 driver:

VFS: Mounted root (ext3 filesystem) on device 179:5.
Freeing init memory: 144K
 * Filesystem type 'fusectl' is not supported. Skipping mount.
 * Setting hostname to 'vishnu'...                                       [ OK ]
 * Setting preliminary keymap...                                         [ OK ]
Interfaces that are up at the moment:
...there, you have it.
 * Starting kernel event manager...                                      [ OK ]
 * Loading hardware drivers...                                                  NET: Registered protocol family 10
ADDRCONF(NETDEV_UP): eth0: link is not ready
                                                                         [ OK ]
Interfaces that are up at the moment:
eth0: link up, 1000 Mb/s, full duplex, flow control disabled
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0      Link encap:Ethernet  HWaddr 00:50:43:01:d7:08
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::250:43ff:fe01:d708/64 Scope:Link
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:168 (168.0 B)

lo        Link encap:Local Loopback 
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:636 (636.0 B)  TX bytes:636 (636.0 B)

...there, you have it.
 * Loading manual drivers...                                             [ OK ]  * Setting kernel variables (/etc/sysctl.conf)...   

You can see my script being called twice, just before udev activation and after it. Despite of the fact that /etc/init.d/networking hasn't run yet, eth0 is up and happy with its old address. I haven't found any udev rules that might do anything here, and I don't have DHCP server running that might be handing out IP address to that interface (besides, dhclient isn't running at that stage). Looks like really the interface comes back with old ip address, and is already up.

Has anyone seen this behavior? It looks like a bug for me. I can work around it, asking for synchronous mounting of network shares, but that's not a solution for this problem...
Pages: [1]