On Tue, Mar 10, 2009 at 11:40 PM, Jason Andryuk <jandryuk@xxxxxxxxx> wrote:
>> 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).
>
> See logs below. I ran with debug=0x40003. This is on commit
> "ff5010c3e12f1d0da27a5f871c2e3d5333dfbe2f iwl3945: sync tx queue data
> structure with iwlagn" with my patches to make it somewhat usable.
>
>> 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.
>
> The problem is that as I try older commits to find which one introduced
> the original error, I find other problems that need to be solved.
> Hopefully I have finally tracked down the commit,
> "ff5010c3e12f1d0da27a5f871c2e3d5333dfbe2f iwl3945: sync tx queue data
> structure with iwlagn", that introduced the Microcode SW errors.
Looking at ff5010c3e12f1d0da27a5f871c2e3d5333dfbe2f, I found the call
to iwl_reset_qos corrupts priv->iw_mode. It is 2 before the call and
515 after.
I dumped priv for 32 bytes starting at &priv->last_beacon_time and saw this.
iwl data: 00000000: 00 0f 00 ff 03 02 00 00 00 0f 00 ff 03 02 00 00
................
iwl data: 00000010: 00 0f 00 ff 03 02 00 00 00 0f 00 ff 03 02 00 00
................
515 = 0x0203 = 03 02 little endian
We have
struct iwl_ac_qos {
__le16 cw_min;
__le16 cw_max;
u8 aifsn;
u8 reserved1;
__le16 edca_txop;
} __attribute__ ((packed));
and
priv->qos_data.def_qos_parm.ac[0].cw_min = cpu_to_le16(cw_min);
priv->qos_data.def_qos_parm.ac[0].cw_max = cpu_to_le16(cw_max);
priv->qos_data.def_qos_parm.ac[0].aifsn = aifs;
priv->qos_data.def_qos_parm.ac[0].edca_txop = 0;
priv->qos_data.def_qos_parm.ac[0].reserved1 = 0;
and
u16 cw_min = 15; // 0x000f
u16 cw_max = 1023; // 0x03ff
u8 aifs = 2; //0x02
Which corresponds to the dump and what is showing up in iw_mode.
I don't know why things are going wrong though.
One problem I see is the check of staging_rxon instead of
staging39_rxon in iwl_reset_qos.
(priv->staging_rxon.flags & RXON_FLG_SHORT_SLOT_MSK) == 0)
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
