On 1/15/2011 3:12 AM, Janne Snabb wrote: > On Sat, 15 Jan 2011, Janne Snabb wrote: > >> It appears that that the netfront driver fails to get the vif mac >> address which leads to panic shortly afterwards. > > The patch at the bottom of this message solves the problem for me. > After that the current 8.2RC2 system works fine on amd64 with XENHVM > kernel with Xen 4.0.1 (have not tested other versions). > > If the "mac" node does not appear in the front-end vif directory > (does it ever appear there? in my experience no), we fetch a link > to the backend directory for the same vif and try to get the "mac" > node from there. > > I am not sure if this is the proper way to fix this, but it works > for me.
As with most things Xen, there is no official specification for what xenstore nodes are where. If we assume the Linux driver is the definitive reference, then the current FreeBSD driver behavior is correct: http://xenbits.xensource.com/linux-2.6.18-xen.hg?file/5e08fff8dc05/drivers/xen/netfront/netfront.c See talk_to_backend() and the xen_net_read_mac() function. There are two environments that setup the xenstore nodes: the Xen cloud platform, and the more common phython tool stack (aka xend). I haven't reviewed XCP, but Xend populates the MAC node in the frontend's tree unless the "ioemu" tag is in the VIF configuration line for that interface. Why this is the case, I have no idea - again the behavior is not documented. However, it seems reasonable to do what you've done in this patch and to rely on the backend's copy if the frontend's doesn't exist. It would also be good to add support to netfront to maintain the mac node in the frontend tree and to allow it to be set just like a real device. I believe netback will pick up and use the updated MAC value if you bounce the Xenbus connection after making the change. -- Justin _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"