It does sound a little like a race condition. Probabally in the
initialisation order or timing of configuration of the bonding driver.
Some of the messages imply that actions are being done in the wrong
order:
[ 6.405552] bonding: bond0: doing slave updates when interface is
down.
First, I see we have the dmesg ordering for the failed setup, it would
be instructive to have the same information for the successful manual
configuration.
Second, it might be interesting to see if we can work round this issue
by triggering the bonding driver to load earlier in boot. Could we try
adding it to /etc/modules. I would also recommend a second test with a
module configuration for that module in /etc/modprobe.d, specifically
setting the parameters as in the manual test case: mode=active-backup
miimon=100.
Finally, I believe that testing with the LTS backport kernel from
Maverick does correctly initiate the bond. There is one commit between
these two which does talk to races with udev. I have pulled that patch
back as a test and produced test kernels. Could you test the kernels at
the URL below and see if this changes the behaviour. Please include the
dmesg fragments for the binding driver in your report. Kernels are at
the URL below:
http://people.canonical.com/~apw/lp688703-lucid/
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/688703
Title:
[lucid] netxen_nic driver and ethernet bonding broken at boot time
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
