[asterisk-bugs] [Zaptel 0012813]: [patch] race conditions in wct4xxp

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12813 
====================================================================== 
Reported By:                aks
Assigned To:                
====================================================================== 
Project:                    Zaptel
Issue ID:                   12813
Category:                   wct4xxp
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     new
Zaptel Version:             1.4.11 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             06-09-2008 05:15 CDT
Last Modified:              06-09-2008 07:01 CDT
====================================================================== 
Summary:                    [patch] race conditions in wct4xxp
Description: 
I think that you have a few race conditions bugs
Patch:

--- zaptel-1.4.11-orig/kernel/wct4xxp/base.c    2008-05-11
03:57:08.000000000 +0200
+++ zaptel-1.4.11/kernel/wct4xxp/base.c 2008-06-09 12:52:02.000000000
+0200
@@ -378,7 +378,7 @@
 #define WC_GPIOCTL     8
 #define WC_GPIO                9
 #define WC_LADDR       10
-#define WC_LDATA               11
+#define WC_LDATA       11
 #define WC_LCS         (1 << 11)
 #define WC_LCS2                (1 << 12)
 #define WC_LALE                        (1 << 13)
@@ -432,9 +432,9 @@
                 * transactions, some host bridges appear to generate
them.
                 * This delay prevents this.
                 */
+               tmp = __t4_pci_in(wc, WC_VERSION);
                if (!test_bit(T4_LOADING_FW, &wc->checkflag))
                        udelay(3);
-               tmp = __t4_pci_in(wc, WC_VERSION);
                if ((tmp & 0xffff0000) != 0xc01a0000)
                        printk("TE4XXP: Version Synchronization
Error!\n");
        }
@@ -1226,7 +1226,7 @@
                        if (debug & DEBUG_FRAMER) printk("transmiting
XHF|XME\n");
                        t4_framer_cmd_wait(wc, span, FRMR_CMDR_XHF |
FRMR_CMDR_XME);
 #if 0
-                       ts->sigactive = (__t4_framer_in(wc, span,
FRMR_SIS) & FRMR_SIS_XFW) ? 0 : 1;
+                       ts->sigactive = (t4_framer_in(wc, span, FRMR_SIS)
& FRMR_SIS_XFW) ? 0 : 1;
 #endif
                        ++ts->frames_out;
                        if ((debug & DEBUG_FRAMER) && !(ts->frames_out &
0x0f))
@@ -2903,14 +2903,14 @@
        struct t4 *wc = dev_id;
        unsigned int status;

+       spin_lock(&wc->reglock);
        /* Check this first in case we get a spurious interrupt */
        if (unlikely(test_bit(T4_STOP_DMA, &wc->checkflag))) {
                /* Stop DMA cleanly if requested */
                wc->dmactrl = 0x0;
-               t4_pci_out(wc, WC_DMACTRL, 0x00000000);
+               __t4_pci_out(wc, WC_DMACTRL, 0x00000000);
                /* Acknowledge any pending interrupts */
-               t4_pci_out(wc, WC_INTR, 0x00000000);
-               spin_lock(&wc->reglock);
+               __t4_pci_out(wc, WC_INTR, 0x00000000);
                __t4_set_timing_source(wc, 4, 0, 0);
                spin_unlock(&wc->reglock);
                return IRQ_RETVAL(1);
@@ -2919,6 +2919,8 @@
        /* Make sure it's really for us */
        status = __t4_pci_in(wc, WC_INTR);

+       spin_unlock(&wc->reglock);
+
        /* Ignore if it's not for us */
        if (!(status & 0x7)) {
 #ifdef LINUX26
@@ -3019,7 +3021,7 @@
                tasklet_schedule(&wc->t4_tlet);

 #ifndef ENABLE_WORKQUEUES
-       __t4_pci_out(wc, WC_INTR, 0);
+       t4_pci_out(wc, WC_INTR, 0);
 #endif
 #ifdef LINUX26
        return IRQ_RETVAL(1);




====================================================================== 

---------------------------------------------------------------------- 
 aks - 06-09-08 07:01  
---------------------------------------------------------------------- 
Thank you for quick answer, for us it is ügent.

We have Dell PowerEdge 1950 (Xeon quadcore E5410) 2GRAM + + TE420 card.

Asterist asterisk-1.6.0-beta8 + zaptel-1.4.11

I generate with sipp 100-200 calls per second, for testing.

The problem is that we have parity Errors (PCI PERROR). Then I have looked
at concurenncy control of the driver. After #PERROR was my system stalled.
With this patch can I see a few messages from edac module, that TE420 and
Marvel Bridge generated  #PERRROR and the system is much later stalled.
I think there are still missing a few memory barriers in the driver.
Atatached files mcelogging and output on the console 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-09-08 07:01  aks            Note Added: 0088466                          
======================================================================