Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
On 4/29/06, Santiago Leon [EMAIL PROTECTED] wrote: Michael Ellerman wrote: Any chance of getting it into to 2.6.17 ... 2.6.19 perhaps? cheers - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
Michael Ellerman wrote:
Looks like this hit the floor. Any chance of getting it into to 2.6.17
Jeff? AFAICT it should still apply cleanly.
/me knocks politely
Actually, it doesn't apply cleanly anymore. Here's a patch that does.
--
Santiago A. Leon
Power Linux Development
IBM Linux Technology Center
From: Michael Ellerman [EMAIL PROTECTED]
After a kexec the ibmveth driver will fail when trying to register with the
Hypervisor because the previous kernel has not unregistered.
So if the registration fails, we unregister and then try again.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
Acked-by: Anton Blanchard [EMAIL PROTECTED]
Signed-off-by: Santiago Leon [EMAIL PROTECTED]
ibmveth.c | 31 ++-
1 file changed, 26 insertions(+), 5 deletions(-)
Index: kexec/drivers/net/ibmveth.c
===
--- a/drivers/net/ibmveth.c 2006-04-28 13:16:22.244724056 -0500
+++ b/drivers/net/ibmveth.c 2006-04-28 13:29:49.429736784 -0500
@@ -436,6 +436,31 @@ static void ibmveth_cleanup(struct ibmve
ibmveth_free_buffer_pool(adapter, adapter-rx_buff_pool[i]);
}
+static int ibmveth_register_logical_lan(struct ibmveth_adapter *adapter,
+union ibmveth_buf_desc rxq_desc, u64 mac_address)
+{
+ int rc, try_again = 1;
+
+ /* After a kexec the adapter will still be open, so our attempt to
+ * open it will fail. So if we get a failure we free the adapter and
+ * try again, but only once. */
+retry:
+ rc = h_register_logical_lan(adapter-vdev-unit_address,
+ adapter-buffer_list_dma, rxq_desc.desc,
+ adapter-filter_list_dma, mac_address);
+
+ if (rc != H_SUCCESS try_again) {
+ do {
+ rc = h_free_logical_lan(adapter-vdev-unit_address);
+ } while (H_IS_LONG_BUSY(rc) || (rc == H_BUSY));
+
+ try_again = 0;
+ goto retry;
+ }
+
+ return rc;
+}
+
static int ibmveth_open(struct net_device *netdev)
{
struct ibmveth_adapter *adapter = netdev-priv;
@@ -505,11 +530,7 @@ static int ibmveth_open(struct net_devic
ibmveth_debug_printk(receive q @ 0x%p\n,
adapter-rx_queue.queue_addr);
- lpar_rc = h_register_logical_lan(adapter-vdev-unit_address,
-adapter-buffer_list_dma,
-rxq_desc.desc,
-adapter-filter_list_dma,
-mac_address);
+ lpar_rc = ibmveth_register_logical_lan(adapter, rxq_desc, mac_address);
if(lpar_rc != H_SUCCESS) {
ibmveth_error_printk(h_register_logical_lan failed with
%ld\n, lpar_rc);
Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
On Mon, 2006-03-27 at 12:11 +1100, Michael Ellerman wrote: On Thu, 2006-03-02 at 13:40 -0600, Santiago Leon wrote: From: Michael Ellerman [EMAIL PROTECTED] After a kexec the veth driver will fail when trying to register with the Hypervisor because the previous kernel has not unregistered. So if the registration fails, we unregister and then try again. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] Acked-by: Anton Blanchard [EMAIL PROTECTED] Signed-off-by: Santiago Leon [EMAIL PROTECTED] --- drivers/net/ibmveth.c | 32 ++-- 1 files changed, 26 insertions(+), 6 deletions(-) Looks like this hit the floor. Any chance of getting it into to 2.6.17 Jeff? AFAICT it should still apply cleanly. /me knocks politely -- Michael Ellerman IBM OzLabs wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part
Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
On Thu, 2006-03-02 at 13:40 -0600, Santiago Leon wrote: From: Michael Ellerman [EMAIL PROTECTED] After a kexec the veth driver will fail when trying to register with the Hypervisor because the previous kernel has not unregistered. So if the registration fails, we unregister and then try again. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] Acked-by: Anton Blanchard [EMAIL PROTECTED] Signed-off-by: Santiago Leon [EMAIL PROTECTED] --- drivers/net/ibmveth.c | 32 ++-- 1 files changed, 26 insertions(+), 6 deletions(-) Looks like this hit the floor. Any chance of getting it into to 2.6.17 Jeff? AFAICT it should still apply cleanly. cheers -- Michael Ellerman IBM OzLabs wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
Santiago Leon wrote: From: Michael Ellerman [EMAIL PROTECTED] After a kexec the veth driver will fail when trying to register with the Hypervisor because the previous kernel has not unregistered. So if the registration fails, we unregister and then try again. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] Acked-by: Anton Blanchard [EMAIL PROTECTED] Signed-off-by: Santiago Leon [EMAIL PROTECTED] --- drivers/net/ibmveth.c | 32 ++-- 1 files changed, 26 insertions(+), 6 deletions(-) Looks good to me, and has been around for a couple of months. This seems completely bonkers to me: are resources available? if no free resources try again It makes resource checking pointless. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
On Fri, 3 Mar 2006 11:34, Randy.Dunlap wrote: On Fri, 3 Mar 2006 11:22:45 +1100 Michael Ellerman wrote: Hi Jeff, I realise it's late, but it'd be really good if you could send this up for 2.6.16, we're hosed without it. I'm wondering if this means that for every virtual/hypervisor situation, we have to modify any $interested_drivers. Why wouldn't we come up with a cleaner solution (in the long term)? E.g., could the hypervisor know when one of it's virtual OSes dies or reboots and release its resources then? It does exactly that for a regular reboot, but when we kexec we _don't_ die or reboot, as far as the Hypervisor is concerned it's all systems go. It's something of a double-edged sword, we're totally in control which gives us lots of flexibility, and _fast_ reboot times, but we also have to do a bit of extra stuff (ie. this patch) to keep things sane. cheers -- Michael Ellerman IBM OzLabs wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person pgpn4pcElGuv6.pgp Description: PGP signature
Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec
On Fri, 3 Mar 2006 12:10:47 +1100 Michael Ellerman wrote: On Fri, 3 Mar 2006 11:34, Randy.Dunlap wrote: On Fri, 3 Mar 2006 11:22:45 +1100 Michael Ellerman wrote: Hi Jeff, I realise it's late, but it'd be really good if you could send this up for 2.6.16, we're hosed without it. I'm wondering if this means that for every virtual/hypervisor situation, we have to modify any $interested_drivers. Why wouldn't we come up with a cleaner solution (in the long term)? E.g., could the hypervisor know when one of it's virtual OSes dies or reboots and release its resources then? It does exactly that for a regular reboot, but when we kexec we _don't_ die or reboot, as far as the Hypervisor is concerned it's all systems go. It's something of a double-edged sword, we're totally in control which gives us lots of flexibility, and _fast_ reboot times, but we also have to do a bit of extra stuff (ie. this patch) to keep things sane. s/this patch/some patch/ Yes, you have certainly thought about this more/longer than I have, so why is something more generic like this bad instead of good: Somewhere early in start_kernel() (e.g.), do an hv call that says free all assigned resources. Maybe hv doesn't know all assigned resources. Maybe it's just that this patch is simpler than an hv change, although this (current) patch could leave some other drivers that need to be fixed, while an hv change wouldn't do that. So I'm not opposed to this current patch as a short-term solution, but I don't think it's the right long-term solution. --- ~Randy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
