Re: [PATCH 2.6.19-git19] BUG due to bad argument to ieee80211softmac_assoc_work
Michael, I sent a patch to this list on Sunday, that patched the problem. It seems to be migrated into the wireless-2.6 git tree. Regards, Uli Am 13.12.2006 um 19:17 schrieb Michael Bommarito: This didn't get much attention on bugzilla and I figured it was important enough to forward along to the whole list since it's been lingering around in ieee80211-softmac since 19-git5 at least. http://bugzilla.kernel.org/show_bug.cgi?id=7657 Somebody was passing the whole mac device structure to ieee80211softmac_assoc_work instead of just the assocation work, which lead to much death and locking. Attached is a patch that fixes this (the actual change is two lines but context provided in patch for review). The dmesg containing call trace is attached to the bugzilla entry above. -Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Uli Kunitz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
Johannes Berg wrote:
I'm not so sure about this. This patching might be US-specific and we
cannot simply apply the setting for top channel of another domain
instead of channel 11. One option would be to set the value only under
the US regulatory domain.
??
What the patch does is replace the top channel which is hardcoded to 11
by the top channel given by the current regulatory domain. How can that
be wrong? Except that you may want to init the regulatory domain from
the EEPROM but I'm not sure how the ieee80211 code works wrt. that.
johannes
The problem is not so much that I don't trust the geo code, but whether
setting the register to that band-edge value for a higher channel is
the right thing to do. It looks like that this is a hack for FFC
compliance. Therefore I suggest to patch CR128 only
for the US regulatory domain.
Here is the code from the GPL vendor driver (zdhw.c):
if (pObj->HWFeature & BIT_21) //6321 for FCC regulation, enabled HWFeature
6M band edge bit (for AL2230, AL2230S)
{
if (ChannelNo == 1 || ChannelNo == 11) //MARK_003, band edge, these
may depend on PCB layout
{
pObj->SetReg(reg, ZD_CR128, 0x12);
pObj->SetReg(reg, ZD_CR129, 0x12);
pObj->SetReg(reg, ZD_CR130, 0x10);
pObj->SetReg(reg, ZD_CR47, 0x1E);
}
else //(ChannelNo 2 ~ 10, 12 ~ 14)
{
pObj->SetReg(reg, ZD_CR128, 0x14);
pObj->SetReg(reg, ZD_CR129, 0x12);
pObj->SetReg(reg, ZD_CR130, 0x10);
pObj->SetReg(reg, ZD_CR47, 0x1E);
}
}
The patch from Holden would set ZD_CR128 to 0x12 for the highest channel,
which would not reflect the logic of the vendor driver.
Kind regards,
Uli
--
Uli Kunitz ([EMAIL PROTECTED])
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] wireless-2.6 zd1211rw check against regulatory domain rather than hardcoded value of 11
Daniel Drake wrote: Holden Karau wrote: I've changed the patch based on your suggestions :-) Thanks, looks fine. Let's just wait for an OK from Ulrich, then you can send it to John, without broken tabs/lines, with signoff and description. Daniel I'm not so sure about this. This patching might be US-specific and we cannot simply apply the setting for top channel of another domain instead of channel 11. One option would be to set the value only under the US regulatory domain. Kind regards, Uli -- Uli Kunitz ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Scanning in ieee80211 softmac layer and setting essid (newbie)
Ian Brown wrote: > My question is : why is this scanning needed when set essid is called? > and why is the repeatition? ESSID doesn't tell you the channel nummber, so you have to scan for a beacon containing the ESSID in passive scanning. Even if you do active scanning you need to check all channels because your ESSID could be on anyone of the channels. Uli -- Uli Kunitz - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
Larry Finger wrote: > Uli Kunitz wrote: > > Larry Finger wrote: > > > > > * A new routine (ieee80211_init_geo ?) will be written to be called by the > > > driver to load the geo structure into the kernel. Information passed to > > > the > > > daemon will be the country code in ASCII and whether the interface is to > > > be > > > used indoors or outdoors. > > > > Would it be possible to support the regulatory domain codes as > > used in the outdated table 105 in Corrigendum 1 for 802.11b? The > > ZD1211 EEPROM contains only this code. An easy translation > > function would be sufficient. Maybe the group codes could be > > misused for it. > > That certainly shouldn't be any difficulty. It could be done in the ZD1211 > driver before it calls the ieee80211_init_geo routine, or it could be done in > the regulatory daemon. I assume that the EEPROM contains X'10' for FCC > regulations, X'31' for Spain, etc. > > Larry Yes, it could be done in the driver. But if there are other drivers having the same issue, the helper function should be integrated in the geo code. Uli -- Uli Kunitz - [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
Larry Finger wrote: > * A new routine (ieee80211_init_geo ?) will be written to be called by the > driver to load the geo structure into the kernel. Information passed to the > daemon will be the country code in ASCII and whether the interface is to be > used indoors or outdoors. Would it be possible to support the regulatory domain codes as used in the outdated table 105 in Corrigendum 1 for 802.11b? The ZD1211 EEPROM contains only this code. An easy translation function would be sufficient. Maybe the group codes could be misused for it. Uli -- Uli Kunitz ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
