On Thu, 2008-01-10 at 17:08 -0700, dann frazier wrote: > On Mon, Jan 07, 2008 at 09:59:10AM +0100, Xavier Poinsard wrote: > > Package: linux-image-2.6.18-5-xen-686 > > Version: 2.6.18.dfsg.1-17 > > Severity: important > > > > > > The shipped version of the bnx2 driver fails to work with xen bridging. > > With an updated version like this one : > > http://linux.dell.com/files/bnx2/xen-fix/ > > the network driver is working. This bug fix is detailled in the driver > > changelog. > > Updating this driver would save many users of xen having this broadcom > > network card. > > hey Xavier, > This seems like a reasonable bug to fix in a stable update. However > an important part of accepting something into a stable release > (possibly the most important part) is demonstrating a high confidence > that this will not break things for other users. Since this patch > requires a firmware blob update, its not possible for us to do that > with this patch alone. > > Michael: Do you know (and can you share) what the changes were to the > fw in this changeset? > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=af3ee519c5d6bebbda9bf0ca3b81bc50b4dd2163 >
This is the actual firmware patch that fixed the problem: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7510873d8659f4192cb5b3327f748e401d216399 Xen puts the networking device in promiscuous mode and programs the MAC address to fe:ff:ff:ff:ff:ff. The network stack continues to use the factory programmed MAC address of the NIC. This should normally be OK since we are in promiscuous mode and should be able to receive all packets. There was however a flaw in the firmware when the NIC was configured like this with management firmware also running. Management firmware also uses the same factory programmed MAC address. In such a configuration, packets addressed to the NIC's factory address would be delivered to management firmware only but not to the Linux driver. This was clearly a bug as promiscuous mode should include reception of all packets. I think the firmware programmer did not foresee such a scenario and our test cases did not include something like this. So the change in the firmware was to correct this bug. It has been lab and field tested for over a year. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
