Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work

2006-05-28 Thread Jason Lunz
On Sun, May 28, 2006 at 06:29:01PM +0200, Michael Buesch wrote:
 Well, I would like to know it for sure. ;)
 Could you load the kernel which crashed and look there. It is
 quite important to know if it is caused by a shared IRQ or not.

OK, i'm running the kernel that crashed now. it's the same:

Linux opus 2.6.17-rc5-git3-suspend2 #2 SMP PREEMPT Sat May 27 14:17:15 EDT 2006 
x86_64 GNU/Linux
   CPU0   
  0:  32010IO-APIC-edge  timer
  1:490IO-APIC-edge  i8042
  7:  3IO-APIC-edge  parport0
  8:  0IO-APIC-edge  rtc
  9:150   IO-APIC-level  acpi
 12:120IO-APIC-edge  i8042
 14:   5428IO-APIC-edge  ide0
 15:841IO-APIC-edge  ide1
 16:  4   IO-APIC-level  yenta, ohci1394
 17:  1   IO-APIC-level  yenta, rtk
 18:  0   IO-APIC-level  ehci_hcd:usb1, NVidia nForce3
 19:  0   IO-APIC-level  ohci_hcd:usb2, NVidia nForce3 Modem
 20:  0   IO-APIC-level  ohci_hcd:usb3
 21:   1559   IO-APIC-level  bcm43xx
NMI: 50 
LOC:  31972 
ERR:  0
MIS:  0

Jason
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev


Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work

2006-05-28 Thread Michael Buesch
On Sunday 28 May 2006 18:37, you wrote:
 On Sun, May 28, 2006 at 06:29:01PM +0200, Michael Buesch wrote:
  Well, I would like to know it for sure. ;)
  Could you load the kernel which crashed and look there. It is
  quite important to know if it is caused by a shared IRQ or not.
 
 OK, i'm running the kernel that crashed now. it's the same:

Ok Jason, could you please test the following patch and try to reproduce
with it?

Jory, could you also test this patch on your machine with the shared
bcm43xx IRQ? While testing, put some load on one of the devices sharing
the IRQ with bcm43xx (I think it was eth0 for example).


Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx.h2006-05-28 
23:57:01.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx.h 2006-05-29 
00:16:50.0 +0200
@@ -647,9 +647,7 @@
void __iomem *mmio_addr;
unsigned int mmio_len;
 
-   /* Do not use the lock directly. Use the bcm43xx_lock* helper
-* functions, to be MMIO-safe. */
-   spinlock_t _lock;
+   spinlock_t lock;
 
/* Driver status flags. */
u32 initialized:1,  /* init_board() succeed */
@@ -704,6 +702,9 @@
/* Number of available 80211 cores. */
int nr_80211_available;
 
+   /* If 0, the MAC is enabled. Suspended otherwise. */
+   int mac_suspended;
+
u32 chipcommon_capabilities;
 
/* Reason code of the last interrupt. */
@@ -744,6 +745,7 @@
/* Debugging stuff follows. */
 #ifdef CONFIG_BCM43XX_DEBUG
struct bcm43xx_dfsentry *dfsentry;
+   atomic_t periodic_work_in_progress;
 #endif
 };
 
@@ -753,8 +755,8 @@
  * the *_mmio lock functions.
  * MMIO read-access is allowed, though.
  */
-#define bcm43xx_lock(bcm, flags)   spin_lock_irqsave((bcm)-_lock, flags)
-#define bcm43xx_unlock(bcm, flags) spin_unlock_irqrestore((bcm)-_lock, 
flags)
+#define bcm43xx_lock(bcm, flags)   spin_lock_irqsave((bcm)-lock, flags)
+#define bcm43xx_unlock(bcm, flags) spin_unlock_irqrestore((bcm)-lock, 
flags)
 /* bcm43xx_(un)lock_mmio() protect struct bcm43xx_private and MMIO.
  * MMIO write-access to the device is allowed.
  * All MMIO writes are flushed on unlock, so it is guaranteed to not
Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c   
2006-05-28 23:57:01.0 +0200
+++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c2006-05-29 
00:41:58.0 +0200
@@ -496,20 +496,36 @@
return old_mask;
 }
 
-/* Make sure we don't receive more data from the device. */
+/* Disable IRQs on the device and make sure no IRQ handler
+ * (or tasklet) is running on return.
+ */
 static int bcm43xx_disable_interrupts_sync(struct bcm43xx_private *bcm, u32 
*oldstate)
 {
u32 old;
unsigned long flags;
+   unsigned int irq;
 
bcm43xx_lock_mmio(bcm, flags);
-   if (bcm43xx_is_initializing(bcm) || bcm-shutting_down) {
+   if (unlikely(bcm43xx_is_initializing(bcm) ||
+bcm-shutting_down)) {
bcm43xx_unlock_mmio(bcm, flags);
return -EBUSY;
}
+   bcm43xx_mac_suspend(bcm);
+   irq = bcm-irq;
old = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
-   tasklet_disable(bcm-isr_tasklet);
+   bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_MASK); /* dummy read. */
+
+   /* Unlock, so running IRQ handlers or tasklets can return
+* and don't deadlock.
+* The access of isr_tasklet after unlocking is Ok, because
+* it can not race after synchronizing IRQ.
+*/
bcm43xx_unlock_mmio(bcm, flags);
+
+   synchronize_irq(irq);
+   tasklet_disable(bcm-isr_tasklet);
+
if (oldstate)
*oldstate = old;
 
@@ -1868,8 +1884,9 @@
if (!bcm)
return IRQ_NONE;
 
-   spin_lock(bcm-_lock);
-
+   /* Do the reason checking unlocked, as we could otherwise deadlock
+* with the periodic work handler.
+*/
reason = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
if (reason == 0x) {
/* irq not for us (shared irq) */
@@ -1880,6 +1897,9 @@
if (!reason)
goto out;
 
+   assert(!atomic_read(bcm-periodic_work_in_progress));
+   spin_lock(bcm-lock);
+
bcm-dma_reason[0] = bcm43xx_read32(bcm, BCM43xx_MMIO_DMA1_REASON)
  0x0001dc00;
bcm-dma_reason[1] = bcm43xx_read32(bcm, BCM43xx_MMIO_DMA2_REASON)
@@ -1907,7 +1927,7 @@
 
 out:
mmiowb();
-   spin_unlock(bcm-_lock);
+   spin_unlock(bcm-lock);
 
return ret;
 }
@@ -2271,13 +2291,17 @@
 /* http://bcm-specs.sipsolutions.net/EnableMac */
 void 

Re: [PATCH, RTF/RFC] bcm43xx: Enable local IRQs while executing periodic work

2006-05-28 Thread Jory A. Pratt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Buesch wrote:
 On Sunday 28 May 2006 18:37, you wrote:
 On Sun, May 28, 2006 at 06:29:01PM +0200, Michael Buesch wrote:
 Well, I would like to know it for sure. ;)
 Could you load the kernel which crashed and look there. It is
 quite important to know if it is caused by a shared IRQ or not.
 OK, i'm running the kernel that crashed now. it's the same:
 
 Ok Jason, could you please test the following patch and try to reproduce
 with it?
 
 Jory, could you also test this patch on your machine with the shared
 bcm43xx IRQ? While testing, put some load on one of the devices sharing
 the IRQ with bcm43xx (I think it was eth0 for example).
 

I have tested the hell out of the patch works great so far, no crash
nothing of bad news to report here. I have done some intesive testing
with eth0 and also done major testing with acpi as I disabled noapic on
the boot options. So finall words would be to push it to 2.6.17-rc* as I
am sure it will be a few more release canadites before it rolls out as
final.

Jory


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEelE1GDfjNg8unQIRAjAtAJ4k1CBAX1sX8li4hHzQkjdnwvovwQCdGAWm
Gj7la0sFPldjftUP+PuSaPI=
=yVFf
-END PGP SIGNATURE-
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev