Skip to contentSkip to conversation

ibmveth: lost IRQ while closing/opening device leads to service loss

PATCH Applied Robert Jennings 2 participants 3 messages Jul 15, 2010 – Jul 16, 2010

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

The order of freeing the IRQ and freeing the device in firmware in ibmveth_close can cause the adapter to become unusable after a subsequent ibmveth_open. Only a reboot of the OS will make the network device usable again. This is seen when cycling the adapter up and down while there is network activity.

There is a window where an IRQ will be left unserviced (H_EOI will not be called). The solution is to make a VIO_IRQ_DISABLE h_call, free the device with firmware, and then call free_irq.

---
 drivers/net/ibmveth.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ibmveth.c +3 -1
Index: b/drivers/net/ibmveth.c
===================================================================
@@ -677,7 +677,7 @@ static int ibmveth_close(struct net_devi
 	if (!adapter->pool_config)
 		netif_stop_queue(netdev);
 
-	free_irq(netdev->irq, netdev);
+	h_vio_signal(adapter->vdev->unit_address, VIO_IRQ_DISABLE);
 
 	do {
 		lpar_rc = h_free_logical_lan(adapter->vdev->unit_address);
@@ -689,6 +689,8 @@ static int ibmveth_close(struct net_devi
 				     lpar_rc);
 	}
 
+	free_irq(netdev->irq, netdev);
+
 	adapter->rx_no_buffer = *(u64*)(((char*)adapter->buffer_list_addr) + 4096 - 8);
 
 	ibmveth_cleanup(adapter);
#1 lore raw

PATCH 1/1 ibmveth: lost IRQ while closing/opening device leads to service loss

The order of freeing the IRQ and freeing the device in firmware in ibmveth_close can cause the adapter to become unusable after a subsequent ibmveth_open. Only a reboot of the OS will make the network device usable again. This is seen when cycling the adapter up and down while there is network activity.

There is a window where an IRQ will be left unserviced (H_EOI will not be called). The solution is to make a VIO_IRQ_DISABLE h_call, free the device with firmware, and then call free_irq.

---
No changes to the patch, I realized I left out '[PATCH]' in the subject and I didn't want any automated tools missing this fix.

---
 drivers/net/ibmveth.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ibmveth.c +3 -1
Index: b/drivers/net/ibmveth.c
===================================================================
@@ -677,7 +677,7 @@ static int ibmveth_close(struct net_devi
 	if (!adapter->pool_config)
 		netif_stop_queue(netdev);
 
-	free_irq(netdev->irq, netdev);
+	h_vio_signal(adapter->vdev->unit_address, VIO_IRQ_DISABLE);
 
 	do {
 		lpar_rc = h_free_logical_lan(adapter->vdev->unit_address);
@@ -689,6 +689,8 @@ static int ibmveth_close(struct net_devi
 				     lpar_rc);
 	}
 
+	free_irq(netdev->irq, netdev);
+
 	adapter->rx_no_buffer = *(u64*)(((char*)adapter->buffer_list_addr) + 4096 - 8);
 
 	ibmveth_cleanup(adapter);
maintainer Applied
#2 lore raw

From: Robert Jennings <[email protected]>
Date: Fri, 16 Jul 2010 09:57:25 -0500

Quoted 11 lines

The order of freeing the IRQ and freeing the device in firmware in ibmveth_close can cause the adapter to become unusable after a subsequent ibmveth_open. Only a reboot of the OS will make the network device usable again. This is seen when cycling the adapter up and down while there is network activity.

There is a window where an IRQ will be left unserviced (H_EOI will not be called). The solution is to make a VIO_IRQ_DISABLE h_call, free the device with firmware, and then call free_irq.

Applied, thanks.

Quoted 2 lines

No changes to the patch, I realized I left out '[PATCH]' in the subject and I didn't want any automated tools missing this fix.

Rules may be sometimes seen as anal, but they are not _that_ anal.

Also you can always look in patchwork to see if your change is there, and your original patch was.

You actually make more work for me if you resubmit patches already sitting in the queue :-/