search for: dev_set_mac_address

Hello, I am trying to bond two ethernet cards together, they are listed as e1000e in the modprobe.conf file. However I keep getting this error: bonding: bond1: Error: dev_set_mac_address of dev eth2 failed! ALB mode requires that the base driver support setting the hw address also when the network device's interface is open Does anyone know how to correctly bond them in CentOs 5.2? Thanks!

...000000 ffffb06e41043772 ffffb06e41043720 ffffffffc0051123 ffff9d50a3583240 0000000087654321 0000000000000002 0000000000000000 0000000000000000 0000000000000000 000000007b8f5301 Call Trace: [<ffffffffc0051123>] virtnet_set_mac_address+0xb3/0x140 [virtio_net] [<ffffffffbc7ae305>] dev_set_mac_address+0x55/0xc0 [<ffffffffc03f319e>] bond_enslave+0x34e/0x1180 [bonding] [<ffffffffbc7ca22f>] do_setlink+0x6cf/0xd10 [<ffffffffbc20dd6a>] ? get_page_from_freelist+0x6ba/0xca0 [<ffffffffbc037de9>] ? sched_clock+0x9/0x10 [<ffffffffbc068475>] ? kvm_sched_clock_read+0x...

...000000 ffffb06e41043772 ffffb06e41043720 ffffffffc0051123 ffff9d50a3583240 0000000087654321 0000000000000002 0000000000000000 0000000000000000 0000000000000000 000000007b8f5301 Call Trace: [<ffffffffc0051123>] virtnet_set_mac_address+0xb3/0x140 [virtio_net] [<ffffffffbc7ae305>] dev_set_mac_address+0x55/0xc0 [<ffffffffc03f319e>] bond_enslave+0x34e/0x1180 [bonding] [<ffffffffbc7ca22f>] do_setlink+0x6cf/0xd10 [<ffffffffbc20dd6a>] ? get_page_from_freelist+0x6ba/0xca0 [<ffffffffbc037de9>] ? sched_clock+0x9/0x10 [<ffffffffbc068475>] ? kvm_sched_clock_read+0x...

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Second version, all feedback so far addressed, thanks for the help and interest! The patch to iproute2 has not changed, so I'm not including it this time. Patch 4/4 (the netlink interface) is basically unchanged as well but included for completeness. The other changes have moved forward a bit, to the point where I find them a lot cleaner and am more confident in the code being ready for

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

Not many changes this time, just integrated a bug fix and all the coding style feedback from Eric Dumazet and Patrick McHardy. I'll keep the patch for network namespaces on the tx path out of this series for now, because the discussion is still ongoing and it addresses an unrelated issue. --- Version 2 description: The patch to iproute2 has not changed, so I'm not including it this

...turn -EFAULT; return 0; case SIOCSIFHWADDR: - { - /* try to set the actual net device's hw address */ - int ret; + /* Set hw address */ + DBG(KERN_DEBUG "%s: set hw address: %s\n", + tun->dev->name, print_mac(mac, ifr.ifr_hwaddr.sa_data)); rtnl_lock(); ret = dev_set_mac_address(tun->dev, &ifr.ifr_hwaddr); rtnl_unlock(); - - if (ret == 0) { - /** Set the character device's hardware address. This is used when - * filtering packets being sent from the network device to the character - * device. */ - memcpy(tun->dev_addr, ifr.ifr_hwaddr.sa_data, -...

...turn -EFAULT; return 0; case SIOCSIFHWADDR: - { - /* try to set the actual net device's hw address */ - int ret; + /* Set hw address */ + DBG(KERN_DEBUG "%s: set hw address: %s\n", + tun->dev->name, print_mac(mac, ifr.ifr_hwaddr.sa_data)); rtnl_lock(); ret = dev_set_mac_address(tun->dev, &ifr.ifr_hwaddr); rtnl_unlock(); - - if (ret == 0) { - /** Set the character device's hardware address. This is used when - * filtering packets being sent from the network device to the character - * device. */ - memcpy(tun->dev_addr, ifr.ifr_hwaddr.sa_data, -...

Looks like the GSO is involved? I got this while running Dom0 only (no guests), with a BOINC/Rosetta@home application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). ------------[ cut here ]------------ kernel BUG at net/core/dev.c:1133! invalid opcode: 0000 [#1] SMP CPU: 0 EIP: 0061:[<c04dceb0>] Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen

This patch series resurrects the earlier multiple TX/RX queues functionality for virtio_net, and addresses the issues pointed out. It also includes an API to share irq's, f.e. amongst the TX vqs. I plan to run TCP/UDP STREAM and RR tests for local->host and local->remote, and send the results in the next couple of days. patch #1: Introduce VIRTIO_NET_F_MULTIQUEUE patch #2: Move

This patch series resurrects the earlier multiple TX/RX queues functionality for virtio_net, and addresses the issues pointed out. It also includes an API to share irq's, f.e. amongst the TX vqs. I plan to run TCP/UDP STREAM and RR tests for local->host and local->remote, and send the results in the next couple of days. patch #1: Introduce VIRTIO_NET_F_MULTIQUEUE patch #2: Move

As multi-queue nics were commonly used for high-end servers, current single queue based tap can not satisfy the requirement of scaling guest network performance as the numbers of vcpus increase. So the following series implements multiple queue support in tun/tap. In order to take advantages of this, a multi-queue capable driver and qemu were also needed. I just rebase the latest version of

As multi-queue nics were commonly used for high-end servers, current single queue based tap can not satisfy the requirement of scaling guest network performance as the numbers of vcpus increase. So the following series implements multiple queue support in tun/tap. In order to take advantages of this, a multi-queue capable driver and qemu were also needed. I just rebase the latest version of