> I am finding it hard to keep track of things as what works and what does > not work appears to shift. I did install a 64bit system in the hopes of > reproducing your issue but could not with a basic open connect. How do > you connect to the AP? Please provide details that you think will enable > me to reproduce. I am trying to connect to an unencrypted 802.11b AP. Back in January, after first encountering the BUG, I attempted a git bisect, but I ran into problems. >From earlier git bisect attempts, I found commit "738910c064ff461051cd37e17199f270ff88a9a3 iwl3945: use rx queue management infrastructure from iwlcore" is the first to trigger the original BUG_ON. "commit cbd8b90ffd8a321ffb2a705733729f0d5ebb20f9 iwl3945: iwl3945_queue and iwl3945_channel_info replacement" worked successfully. Unfortunately, the conversion of iwl3945 leaves the driver inoperable at many places between the two commits above, so a bisect fails on account of other issues. I have been spending time progressing from cbd8b90f... to 738910c0... and fixing issues as encountered. Following the commits on this page, http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=shortlog;h=738910c064ff461051cd37e17199f270ff88a9a3 , I am trying to get from "cbd8b90ffd8a321ffb2a705733729f0d5ebb20f9 iwl3945: iwl3945_queue and iwl3945_channel_info replacement" to the top. While doing that, I have to fix errors to get the driver functional. Basically, I am doing a manual bisect where I have to fix the errors at each stage. But it isn't truly a bisect as I am progressing from cbd8b90f... to 738910c0... On Tue, Mar 10, 2009 at 1:04 AM, reinette chatre <reinette.chatre@xxxxxxxxx> wrote: > Hi Jason, > > On Mon, 2009-03-09 at 18:40 -0700, Jason Andryuk wrote: >> I thought I had made a big breakthrough when I found the solution to >> getting >> "iwlwifi: use iwl_cmd instead of iwl3945_cmd" >> bb64785ad94d575fe4f5f9e69f4f6c0b24e9905d to work. Then I discovered >> that casting to iwl3945_tx_cmd was fixed later by "iwl3945: use >> iwl3945_tx_cmd instead of iwl_tx_cmd" fadd267e... > > > Does this mean if you apply commit fadd267e on top of > bb64785ad94d575fe4f5f9e69f4f6c0b24e9905d then things work? No. My patch, which is basically fadd267e..., completes the transition of bb64785ad94d575fe4f5f9e69f4f6c0b24e9905d and allows the driver to work at *that* stage. bb64785ad94d575fe4f5f9e69f4f6c0b24e9905d and fadd267e should have been one commit. >> >> However, with this new knowledge, I was able to get farther. >> >> Using my iwl3945_tx_cmd conversion patch, > > Is this the last patch you emailed? I don't have the patch in front of me, but it is basically fadd267e >> a patch for allocating rb_stts It is basically the reverse of this patch from Sam Ortiz *I think*. Again, I don't have it in front of me. Commit " c2a0aa3cb733452e749727680e380dca6cc10a68 iwl3945: use iwl_rb_status" has a NULL pointer dereference since it doesn't allocate rb_stts. --- drivers/net/wireless/iwlwifi/iwl-rx.c | 8 -------- 1 file changed, 8 deletions(-) Index: wireless-testing/drivers/net/wireless/iwlwifi/iwl-rx.c =================================================================== --- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-rx.c 2009-01-27 17:13:46.000000000 +0100 +++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-rx.c 2009-01-27 17:15:46.000000000 +0100 @@ -346,11 +346,6 @@ int iwl_rx_queue_alloc(struct iwl_priv * if (!rxq->bd) goto err_bd; - rxq->rb_stts = pci_alloc_consistent(dev, sizeof(struct iwl_rb_status), - &rxq->rb_stts_dma); - if (!rxq->rb_stts) - goto err_rb; - /* Fill the rx_used queue with _all_ of the Rx buffers */ for (i = 0; i < RX_FREE_BUFFERS + RX_QUEUE_SIZE; i++) list_add_tail(&rxq->pool[i].list, &rxq->rx_used); @@ -362,9 +357,6 @@ int iwl_rx_queue_alloc(struct iwl_priv * rxq->need_update = 0; return 0; -err_rb: - pci_free_consistent(priv->pci_dev, 4 * RX_QUEUE_SIZE, rxq->bd, - rxq->dma_addr); err_bd: return -ENOMEM; } >> and a patch for the BUG_ON -> WARN_ON, > > ... and this one This is your patch from January 9 diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c index a23d51d..09c1c8d 100644 --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c @@ -3118,7 +3118,14 @@ static void iwl3945_tx_cmd_complete(struct iwl_priv *priv, int cmd_index; struct iwl_cmd *cmd; - BUG_ON(txq_id != IWL_CMD_QUEUE_NUM); + if (WARN(txq_id != IWL_CMD_QUEUE_NUM, + "wrong command queue %d, sequence 0x%X readp=%d writep=%d\n", + txq_id, sequence, + priv->txq[IWL_CMD_QUEUE_NUM].q.read_ptr, + priv->txq[IWL_CMD_QUEUE_NUM].q.write_ptr)) { + iwl_print_hex_dump(priv, IWL_DL_INFO , rxb, 32); + return; + } cmd_index = get_cmd_index(&priv->txq[IWL_CMD_QUEUE_NUM].q, index, huge); cmd = priv->txq[IWL_CMD_QUEUE_NUM].cmd[cmd_index]; >> I was able to narrow down commit >> "iwl3945: sync tx queue data structure with iwlagn" >> ff5010c3e12f1d0da27a5f871c2e3d5333dfbe2f as the one that starts >> introducing Microcode SW errors. >> > > I am not sure how your repository looks at this stage. What is your > latest wireless-testing commit and what patches do you have on top of > it? The repo looks like this: git checkout -f ff5010c3e12f1d0da27a5f871c2e3d5333dfbe2f patch -p1 < ../iwl-tx-cmd-conversion.patch patch -p1 < ../iwl-rb_stts.patch patch -p1 < ../iwl-BUG-to-WARN.patch The previous commit with the above patches works. >> I tried adding in Reinette's iwl3945_hw_txq_free_tfd pci_unmap_single >> patch from earlier, but it did not fix the problem. >> >> Would TX debugging output be more helpful? > > You log below has a new error (similar to what you note in your next > email). "Unsupported interface type 515". This is very strange and > really looks like some corruption as this value is initialized with a > macro during probe. Could you enable mac and info debugging also (add > 0x3 to your current debug flags)? This code has also changed a bit since > commit bb64785ad94d575fe4f5f9e69f4f6c0b24e9905d. > > You can also put a dump_stack() in iwl3945_connection_init_rx_config to > see where the call comes from and then trace the value of mode to see > where it is set to 515 ... it is supposed to be 2 > (NL80211_IFTYPE_STATION). It may be a little while before I can get back to this. Thanks for looking into it. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
