Re: [PATCH] powerpc: ibmveth: Harden driver initilisation for kexec

2006-08-29 Thread Michael Ellerman

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

2006-04-28 Thread Santiago Leon

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

2006-04-26 Thread Michael Ellerman
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

2006-03-26 Thread Michael Ellerman
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

2006-03-02 Thread Jeff Garzik

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

2006-03-02 Thread Michael Ellerman
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

2006-03-02 Thread Randy.Dunlap
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