#127: madwifi-ng: 2.6.15 kernel panic: fatal exception in irq handler
------------------------------+---------------------------------------------
  Reporter:  schorpp          |       Owner:  mrenzmann                         
  
      Type:  defect           |      Status:  new                               
  
  Priority:  critical         |   Milestone:  version 0.9.0 - move to new 
codebase
 Component:  madwifi: driver  |     Version:  trunk                             
  
Resolution:                   |    Keywords:  panic                             
  
------------------------------+---------------------------------------------
Comment (by schorpp):

 with

 modprobe ath-pci ath_debug=0x00801000

 and some extra printk's here:

 static void
 ath_uapsd_processtriggers(struct ath_softc *sc)
 {
         struct ath_hal *ah = sc->sc_ah;
         struct ath_buf *bf;
         struct ath_desc *ds;
         struct sk_buff *skb;
         struct ieee80211_node *ni;
         struct ath_node *an;
         struct ieee80211_qosframe *qwh;
         struct ath_txq *uapsd_xmit_q = sc->sc_uapsdq;
         struct ieee80211com *ic = &sc->sc_ic;
         int ac, retval;
         u_int8_t tid;
         u_int16_t frame_seq;
         u_int64_t tsf;
 #define PA2DESC(_sc, _pa) \
         ((struct ath_desc *)((caddr_t)(_sc)->sc_rxdma.dd_desc + \
                 ((_pa) - (_sc)->sc_rxdma.dd_desc_paddr)))

         /* XXXAPSD: build in check against max triggers we could see
          *          based on ic->ic_uapsdmaxtriggers.
          */
                         DPRINTF(sc, ATH_DEBUG_UAPSD, "%s: A\n", __func__
 );

         tsf = ath_hal_gettsf64(ah);
         ATH_RXBUF_LOCK(sc);
         if (sc->sc_rxbufcur == NULL)
                 sc->sc_rxbufcur = STAILQ_FIRST(&sc->sc_rxbuf);
         for (bf = sc->sc_rxbufcur; bf; bf = STAILQ_NEXT(bf, bf_list)) {
                 ds = bf->bf_desc;
                 if (ds->ds_link == bf->bf_daddr) {
                         /* NB: never process the self-linked entry at the
 end */
                         break;
                 }
                 if (bf->bf_status & ATH_BUFSTATUS_DONE) {
                         /*
                          * already processed this buffer (shouldn't occur
 if
                          * we change code to always process descriptors in
                          * rx intr handler - as opposed to sometimes
 processing
                          * in the rx tasklet).
                          */
                         continue;
                 }
                 skb = bf->bf_skb;
                 if (skb == NULL) {              /* XXX ??? can this happen
 */
                         printk("%s: no skbuff\n", __func__);
                         continue;
                 }

                 /*
                  * XXXAPSD: consider new hal call that does only the
 subset
                  *          of ath_hal_rxprocdesc we require for trigger
 search.
                  */

                 /*
                  * NB: descriptor memory doesn't need to be sync'd
                  *     due to the way it was allocated.
                  */

                 /*
                  * Must provide the virtual address of the current
                  * descriptor, the physical address, and the virtual
                  * address of the next descriptor in the h/w chain.
                  * This allows the HAL to look ahead to see if the
                  * hardware is done with a descriptor by checking the
                  * done bit in the following descriptor and the address
                  * of the current descriptor the DMA engine is working
                  * on.  All this is necessary because of our use of
                  * a self-linked list to avoid rx overruns.
                  */
                         DPRINTF(sc, ATH_DEBUG_UAPSD, "%s: B\n", __func__
 );
                 retval = ath_hal_rxprocdesc(ah, ds, bf->bf_daddr,
 PA2DESC(sc, ds->ds_link),tsf);
                 if (HAL_EINPROGRESS == retval)
                         break;


 ... it runs now for hours without any issue and the hostapd ap this client
 is connected does no longer need to force by local deauth requests at the
 reauth intervalls.

 so theres wether a synchronisation/timing problem in the hal or maschine
 specific irq/acpi trouble...

 the code part of the 20:09 post is in. commenting it out results in very
 earlier crashes.

 y
 tom

-- 
Ticket URL: <http://madwifi.org/ticket/127>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity

Reply via email to