Hi, I''m trying to fix the following error on netfront, but no sucess until now. 1. Problem: - On netfront_closing we unregister the net device (calling close_netdev) - When the frontend directory on store is removed the netfront_remove() is called, and we call netif_disconnect_backend(), but "&info->tx_lock", "&info->rx_lock" , etc, are not valid anymore and we get an OOOPS. 2. If I call netif_free() from netfront_closing() I get: "WARNING: g.e. still in use! WARNING: leaking g.e. and page still in use! WARNING: g.e. still in use! WARNING: leaking g.e. and page still in use!" Because this pages (info->tx and info->rx) still in use by hypervisor/dom0. 3. If I remove close_netdev() from netfront_closing() everthing seems to work well on begining but: - after some attach and detach I see the same warning, and after some other attach and detach domU freeze. OR - I get some OOPS on "page_waitqueue" Seems to me there is something wrong on memory allocation/deallocation, but I did not find it yet. Ideas? -- Murillo Fernandes Bernardes IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Nov 25, 2005 at 11:05:06AM -0200, Murillo Bernardes wrote:> Hi, > > I''m trying to fix the following error on netfront, but no sucess until now. > > 1. Problem: > - On netfront_closing we unregister the net device (calling close_netdev) > - When the frontend directory on store is removed the netfront_remove() is > called, and we call netif_disconnect_backend(), but "&info->tx_lock", > "&info->rx_lock" , etc, are not valid anymore and we get an OOOPS. > > 2. If I call netif_free() from netfront_closing() I get: > "WARNING: g.e. still in use! > WARNING: leaking g.e. and page still in use! > WARNING: g.e. still in use! > WARNING: leaking g.e. and page still in use!" > > Because this pages (info->tx and info->rx) still in use by hypervisor/dom0.Yes, I''ve been discussing this with Keir and Ian, following your bug report and first patch. It would be nice if we could tear down cleanly, even when packets are in flight, but as you''ve found out, this is quite fiddly, as the backend may hold outstanding references to transmitted packets. The easiest solution might be to simply refuse to close down unless the network interface has been closed down in userspace, and then it should be much easier to close down the driver, because there will be no packets being transmitted. This does not seem like an unreasonable restriction to me. For the receive queue it will be necessary to drop packets in the queue, and remove the grants on that queue so that no more packets are received. This may require more synchronisation between frontend and backend than we have already, I''m not sure. Basically, it''s quite a complicated piece of work still. Network hotplugging has never worked before, and it seems that there is still plenty of work needed on the driver before it can support it. You are more than welcome to work on it, but I think that you probably ought to speak to Keir, who understands the driver better than I do, before plowing in. Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 2005-11-25 at 14:56 +0000, Ewan Mellor wrote:> Yes, I''ve been discussing this with Keir and Ian, following your bug report > and first patch. It would be nice if we could tear down cleanly, even when > packets are in flight, but as you''ve found out, this is quite fiddly, as the > backend may hold outstanding references to transmitted packets. The easiest > solution might be to simply refuse to close down unless the network interface > has been closed down in userspace, and then it should be much easier to close > down the driver, because there will be no packets being transmitted. This > does not seem like an unreasonable restriction to me. > > For the receive queue it will be necessary to drop packets in the queue, and > remove the grants on that queue so that no more packets are received. This > may require more synchronisation between frontend and backend than we have > already, I''m not sure. > > Basically, it''s quite a complicated piece of work still. Network hotplugging > has never worked before, and it seems that there is still plenty of work > needed on the driver before it can support it. You are more than welcome to > work on it, but I think that you probably ought to speak to Keir, who > understands the driver better than I do, before plowing in.The xenidc stuff already works to do this correctly for USB and was designed to be extensible for the different kind of transfer mechanism required by networking. If you eventually choose to accept the xenidc code I can help you to extend it to support the network driver. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel