On Mon, Aug 31, 2009 at 6:39 PM, Leonardo H. Souza
Hamada<[email protected]> wrote:
> Hin-Tak Leung wrote:
>> On Mon, Aug 31, 2009 at 5:39 PM, Leonardo H. Souza
>> Hamada<[email protected]> wrote:
>>
>>> Hi list,
>>>
>>> On linux-2.6.24-gentoo-r3, the zd1211rw driver was working as eth1.
>>>
>>> This is a big-endian machine.
>>>
>>> On 2.6.30-gentoo-r5, 'ifconfig -a' shows the relevant entries below:
>>>
>>
>>
>>> Likely is a issue similar reported previously:
>>> http://marc.info/?l=linux-wireless&m=124906700820860&w=2
>>>
>>> Quick peek at the source diffs between previous version reveals some
>>> changes.
>>>
>>
>> Are you talking about a regression - i.e. it used to work *on the same
>> architecture*, but not any more? If that's the case you can probably
>> start with 2.6.24 and various compat-wireless on to narrow down which
>> changes break. The post you referred to is different - vendor driver
>> vs rw driver.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>> It used to work *on the same architecture*, but not any more.
>
> This is the case.
>
>>The post you referred to is different - vendor driver vs rw driver.
>
> The post i referred to, as I interpret, is a illustrative that the
> vendor driver is working on the same hardware which the rw is not working.
>
> Thanks for the reply anyway .
>
I just had a quick look - the rw driver from 2.6.24 to 2.6.30 actually
went through the ieee80211 to mac80211 change.
('git diff v2.6.24:drivers/net/wireless/zd1211rw/
v2.6.30:drivers/net/wireless/zd1211rw/' for those who has
wireless-testing).
I have a bunch of patches which bring the 2.22 vendor driver up to
2.6.29 and 3.0 the vendor driver up to 2.6.30:
http://htl10.users.sourceforge.net/patchsets/
It doesn't fix the rw driver, but might be good enough for you? I
didn't spent any more time on the 2.22 vendor driver after 2.6.29
because 3.0 was released then. The 3.0 vendor driver can be had from:
http://www.kernel.org/pub/linux/kernel/people/mcgrof/zd1211/
It would appear that the rw driver's ieee80211->mac80211 conversion
has broken big- endian platforms, at a first guess.
( I still maintain that
http://marc.info/?l=linux-wireless&m=124906700820860&w=2 is a bit
different from your situation, since the other poster never had the rw
driver working on bigendian platforms). In any case, it might be
interesting to hear from others if recent versions of the rw driver
can be confirmed to work on bigendian platforms.
On Monday 31 August 2009 20:26:22 Hin-Tak Leung wrote:
> It would appear that the rw driver's ieee80211->mac80211 conversion
> has broken big- endian platforms, at a first guess.
Last time I tested the device worked fine on my powerbook with zd1211rw/mac80211.
But that's maybe two or three release cycles in the past.
--
Greetings, Michael.
On Mon, Aug 31, 2009 at 8:27 PM, Michael Buesch<[email protected]> wrote:
> On Monday 31 August 2009 20:26:22 Hin-Tak Leung wrote:
>> It would appear that the rw driver's ieee80211->mac80211 conversion
>> has broken big- endian platforms, at a first guess.
>
> Last time I tested the device worked fine on my powerbook with zd1211rw/mac80211.
> But that's maybe two or three release cycles in the past.
>
> --
> Greetings, Michael.
>
The rw ieee80211->mac80211 conversion happens in 2.6.27->26.28 ...
Iguess the question is whether it was 2.6.28 or 2.6.27 you had success
with? That's unfortunately two *and* three cycles in the past,
respectively :-).
On Monday 31 August 2009 21:35:31 Hin-Tak Leung wrote:
> On Mon, Aug 31, 2009 at 8:27 PM, Michael Buesch<[email protected]> wrote:
> > On Monday 31 August 2009 20:26:22 Hin-Tak Leung wrote:
> >> It would appear that the rw driver's ieee80211->mac80211 conversion
> >> has broken big- endian platforms, at a first guess.
> >
> > Last time I tested the device worked fine on my powerbook with zd1211rw/mac80211.
> > But that's maybe two or three release cycles in the past.
> >
> > --
> > Greetings, Michael.
> >
>
> The rw ieee80211->mac80211 conversion happens in 2.6.27->26.28 ...
> Iguess the question is whether it was 2.6.28 or 2.6.27 you had success
> with? That's unfortunately two *and* three cycles in the past,
> respectively :-).
>
>
I certainly used zd1211rw/mac80211 and it worked.
--
Greetings, Michael.
On Sun, Sep 13, 2009 at 8:41 PM, Hin-Tak Leung <[email protected]> wrote:
> On Sun, Sep 13, 2009 at 11:13 AM, Hin-Tak Leung <[email protected]> wrote:
>> On Sat, Sep 12, 2009 at 11:43 PM, Leonardo H. Souza Hamada
>> <[email protected]> wrote:
>>> Hi all,
>>>
>>> At this moment, after tweaking the zd1211rw code in kernel
>>> 2.6.31-gentoo, finally I am able to use the WLI-U2-KG54L wireless usb
>>> dongle on this old ibook.
>>>
>>> Browsing the source with a cross referencing tool
>>> (http://lxr.free-electrons.com) and making additional checking points, I
>>> could trace the issue as follow.
>>>
>>> The problem is that this device returns a regulatory region of 0x49,
>>> which is not defined in the zd1211rw tables. So the call
>>>
>>> r <http://lxr.free-electrons.com/ident?i=r> = zd_reg2alpha2 <http://lxr.free-electrons.com/ident?i=zd_reg2alpha2>(mac <http://lxr.free-electrons.com/ident?i=mac>->regdomain, alpha2);
>>>
>>> will fail the initialization process.
>>>
>>>
>>> Workaround:
>>>
>>> ----snip----
>>> int zd_mac_init_hw(struct ieee80211_hw *hw)
>>> {
>>> ...
>>> r = zd_read_regdomain(chip, &default_regdomain);
>>> /* A unknown regulatory of 0x49 will be set default to
>>> ZD_REGDOMAIN_FCC. */
>>> if (0x49 == default_regdomain)
>>> default_regdomain = ZD_REGDOMAIN_FCC;
>>> ...
>>> ----snip----
>>>
>>> The above code will force the default regulatry to be FCC code for this
>>> case. I think that this was the case in previous zd1211rw driver. What
>>> is the country code for 0x49 region? There is a better way?
>>>
>>>
>>> Thanks all,
>>>
>>> Phew!! Leonardo
>>
>> The vendor driver has quite a lot more regdomain code defined, and
>> 0x49 is apparently
>>
>> ZD_Region_Japan_3 = 0x49,//G channel->ch1-13; A channel->8~16,34~46;
>>
>> the rw driver code probably should set it to most restrictive than let
>> it fail...
>>
>
> Can you give this patch a try against a recent
> wireless-testing/compat-wireless? I think this is the correct way to
> do things.
>
> Here is the content of the patch for others who doesn't like
> attachments - it just sets 0x49 as Japan.
> ==============================
> diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c
> b/drivers/net/wireless/zd1211rw/zd_mac.c
> index 6d66635..b0d32c4 100644
> --- a/drivers/net/wireless/zd1211rw/zd_mac.c
> +++ b/drivers/net/wireless/zd1211rw/zd_mac.c
> @@ -42,6 +42,7 @@ static struct zd_reg_alpha2_map reg_alpha2_map[] = {
> { ZD_REGDOMAIN_ETSI, "DE" }, /* Generic ETSI, use most restrictive */
> { ZD_REGDOMAIN_JAPAN, "JP" },
> { ZD_REGDOMAIN_JAPAN_ADD, "JP" },
> + { ZD_REGDOMAIN_JAPAN_3, "JP" },
> { ZD_REGDOMAIN_SPAIN, "ES" },
> { ZD_REGDOMAIN_FRANCE, "FR" },
> };
> diff --git a/drivers/net/wireless/zd1211rw/zd_mac.h
> b/drivers/net/wireless/zd1211rw/zd_mac.h
> index 7c27591..9701935 100644
> --- a/drivers/net/wireless/zd1211rw/zd_mac.h
> +++ b/drivers/net/wireless/zd1211rw/zd_mac.h
> @@ -193,6 +193,7 @@ struct zd_mac {
> #define ZD_REGDOMAIN_FRANCE 0x32
> #define ZD_REGDOMAIN_JAPAN_ADD 0x40
> #define ZD_REGDOMAIN_JAPAN 0x41
> +#define ZD_REGDOMAIN_JAPAN_3 0x49
FWIW, this does seem right.
Luis
On Sun, Sep 13, 2009 at 11:13 AM, Hin-Tak Leung <[email protected]> wrote:
> On Sat, Sep 12, 2009 at 11:43 PM, Leonardo H. Souza Hamada
> <[email protected]> wrote:
>> Hi all,
>>
>> At this moment, after tweaking the zd1211rw code in kernel
>> 2.6.31-gentoo, finally I am able to use the WLI-U2-KG54L wireless usb
>> dongle on this old ibook.
>>
>> Browsing the source with a cross referencing tool
>> (http://lxr.free-electrons.com) and making additional checking points, I
>> could trace the issue as follow.
>>
>> The problem is that this device returns a regulatory region of 0x49,
>> which is not defined in the zd1211rw tables. So the call
>>
>> r <http://lxr.free-electrons.com/ident?i=r> = zd_reg2alpha2 <http://lxr.free-electrons.com/ident?i=zd_reg2alpha2>(mac <http://lxr.free-electrons.com/ident?i=mac>->regdomain, alpha2);
>>
>> will fail the initialization process.
>>
>>
>> Workaround:
>>
>> ----snip----
>> int zd_mac_init_hw(struct ieee80211_hw *hw)
>> {
>> ...
>> r = zd_read_regdomain(chip, &default_regdomain);
>> /* A unknown regulatory of 0x49 will be set default to
>> ZD_REGDOMAIN_FCC. */
>> if (0x49 == default_regdomain)
>> default_regdomain = ZD_REGDOMAIN_FCC;
>> ...
>> ----snip----
>>
>> The above code will force the default regulatry to be FCC code for this
>> case. I think that this was the case in previous zd1211rw driver. What
>> is the country code for 0x49 region? There is a better way?
>>
>>
>> Thanks all,
>>
>> Phew!! Leonardo
>
> The vendor driver has quite a lot more regdomain code defined, and
> 0x49 is apparently
>
> ZD_Region_Japan_3 = 0x49,//G channel->ch1-13; A channel->8~16,34~46;
>
> the rw driver code probably should set it to most restrictive than let
> it fail...
>
Can you give this patch a try against a recent
wireless-testing/compat-wireless? I think this is the correct way to
do things.
Here is the content of the patch for others who doesn't like
attachments - it just sets 0x49 as Japan.
==============================
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c
b/drivers/net/wireless/zd1211rw/zd_mac.c
index 6d66635..b0d32c4 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -42,6 +42,7 @@ static struct zd_reg_alpha2_map reg_alpha2_map[] = {
{ ZD_REGDOMAIN_ETSI, "DE" }, /* Generic ETSI, use most restrictive */
{ ZD_REGDOMAIN_JAPAN, "JP" },
{ ZD_REGDOMAIN_JAPAN_ADD, "JP" },
+ { ZD_REGDOMAIN_JAPAN_3, "JP" },
{ ZD_REGDOMAIN_SPAIN, "ES" },
{ ZD_REGDOMAIN_FRANCE, "FR" },
};
diff --git a/drivers/net/wireless/zd1211rw/zd_mac.h
b/drivers/net/wireless/zd1211rw/zd_mac.h
index 7c27591..9701935 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.h
+++ b/drivers/net/wireless/zd1211rw/zd_mac.h
@@ -193,6 +193,7 @@ struct zd_mac {
#define ZD_REGDOMAIN_FRANCE 0x32
#define ZD_REGDOMAIN_JAPAN_ADD 0x40
#define ZD_REGDOMAIN_JAPAN 0x41
+#define ZD_REGDOMAIN_JAPAN_3 0x49
enum {
MIN_CHANNEL24 = 1,
============================================
Hi all,
At this moment, after tweaking the zd1211rw code in kernel
2.6.31-gentoo, finally I am able to use the WLI-U2-KG54L wireless usb
dongle on this old ibook.
Browsing the source with a cross referencing tool
(http://lxr.free-electrons.com) and making additional checking points, I
could trace the issue as follow.
The problem is that this device returns a regulatory region of 0x49,
which is not defined in the zd1211rw tables. So the call
r <http://lxr.free-electrons.com/ident?i=r> = zd_reg2alpha2 <http://lxr.free-electrons.com/ident?i=zd_reg2alpha2>(mac <http://lxr.free-electrons.com/ident?i=mac>->regdomain, alpha2);
will fail the initialization process.
Workaround:
----snip----
int zd_mac_init_hw(struct ieee80211_hw *hw)
{
...
r = zd_read_regdomain(chip, &default_regdomain);
/* A unknown regulatory of 0x49 will be set default to
ZD_REGDOMAIN_FCC. */
if (0x49 == default_regdomain)
default_regdomain = ZD_REGDOMAIN_FCC;
...
----snip----
The above code will force the default regulatry to be FCC code for this
case. I think that this was the case in previous zd1211rw driver. What
is the country code for 0x49 region? There is a better way?
Thanks all,
Phew!! Leonardo
Some more diagnostic info for the rw driver, this time compiled as
built-in and debug option in the kernel for 2.6.30.
dmesg for rw driver output:
usb 1-2: new high speed USB device using ehci_hcd and address 2
usb 1-2: New USB device found, idVendor=0411, idProduct=00da
usb 1-2: New USB device strings: Mfr=16, Product=32, SerialNumber=0
usb 1-2: Product: USB2.0 WLAN
usb 1-2: Manufacturer: Buffalo
usb 1-2: configuration #1 chosen from 1 choice
usb 1-2: print_id() 0411:00da v4810 high
usb 1-2: reset high speed USB device using ehci_hcd and address 2
zd1211rw 1-2:1.0: zd_chip_read_mac_addr_fw()
phy0: Selected rate control algorithm 'minstrel'
zd1211rw 1-2:1.0: probe() successful
zd1211rw 1-2:1.0: phy0
zd1211rw 1-2:1.0: zd_usb_init_hw()
usb 1-2: request_fw_file() fw name zd1211/zd1211b_ub
usb 1-2: firmware: requesting zd1211/zd1211b_ub
usb 1-2: upload_firmware() firmware device id 0x4810 is equal to the
actual device id
usb 1-2: request_fw_file() fw name zd1211/zd1211b_uphr
usb 1-2: firmware: requesting zd1211/zd1211b_uphr
usb 1-2: upload_code() transfer size 4096
usb 1-2: upload_code() transfer size 1024
usb 1-2: upload_code() firmware confirm return value 0x01
zd1211rw 1-2:1.0: zd_usb_enable_int()
zd1211rw 1-2:1.0: zd_usb_enable_int() submit urb ce577580
zd1211rw 1-2:1.0: zd_chip_init_hw()
zd1211rw 1-2:1.0: dump_cr() CR_AFTER_PNP 0x00000000
zd1211rw 1-2:1.0: dump_cr() CR_GPI_EN 0x00000000
zd1211rw 1-2:1.0: dump_cr() CR_INTERRUPT 0x00000000
zd1211rw 1-2:1.0: read_fw_regs_offset() fw_regs_base: 0xf7f1
zd1211rw 1-2:1.0: read_pod() E2P_POD 0xa000011a
zd1211rw 1-2:1.0: read_pod() RF AL2230S_RF 0xa PA type 0x0 patch CCK 1
patch CR157 0 patch 6M 0 new PHY 1 link LED1 tx led 1
zd1211rw 1-2:1.0: hw_init()
zd1211rw 1-2:1.0: zd1211b_hw_reset_phy()
zd1211rw 1-2:1.0: zd1211b_hw_init_hmac()
zd1211rw 1-2:1.0: zd_usb_rfwrite() value 0x0241000 bits 24
zd1211rw 1-2:1.0: firmware version 4725
zd1211rw 1-2:1.0: dump_fw_registers() FW_FIRMWARE_VER 0x4725
zd1211rw 1-2:1.0: dump_fw_registers() FW_USB_SPEED 0x0001
zd1211rw 1-2:1.0: dump_fw_registers() FW_FIX_TX_RATE 0x0000
zd1211rw 1-2:1.0: dump_fw_registers() FW_LINK_STATUS 0x0000
zd1211rw 1-2:1.0: dump_cr() CR_AFTER_PNP 0x00000001
zd1211rw 1-2:1.0: dump_cr() CR_GPI_EN 0x00000000
zd1211rw 1-2:1.0: dump_cr() CR_INTERRUPT 0x00000000
zd1211rw 1-2:1.0: zd1211b chip 0411:00da v4810 high 00-16-01 AL2230S_RF
pa0 g--N-
zd1211rw 1-2:1.0: zd_read_regdomain() regdomain: 0x49
zd1211rw 1-2:1.0: zd_usb_disable_int() urb ce577580 killed
zd1211rw 1-2:1.0: zd_usb_init_hw() couldn't initialize mac. Error number 1
iwconfig:
lo no wireless extensions.
eth0 no wireless extensions.
tunl0 no wireless extensions.
gre0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11bg ESSID:""
Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated
Tx-Power=0 dBm
Retry min limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Hin-Tak Leung wrote:
> I have a bunch of patches which bring the 2.22 vendor driver up to
> 2.6.29 and 3.0 the vendor driver up to 2.6.30:
> http://htl10.users.sourceforge.net/patchsets/
> It doesn't fix the rw driver, but might be good enough for you?
>
I have downloaded the vendor driver and applied your patchset.
Inserted the vendor { USB_DEVICE(0x0411, 0x00DA) }, in
ar2524drv/src/zdusb.c
Recompiled as zd1211REV_B
dmesg for vendor driver:
udev: starting version 145
_____ ____ _ ____
|__ / _| _ \ / \ / ___|
/ / | | | | | |/ _ \ \___ \
/ /| |_| | |_| / ___ \ ___) |
/____\__, |____/_/ \_\____/
|___/
zd1211 - version 3.0.0.56
vendor_id = 0411
product_id = 00da
USB 2.0 Host
Release Ver = 4810
EEPORM Ver = 4330
Finsih download Firmware. Ready to reboot
Finsih download Firmware. Ready to reboot
Finsih download Firmware. Ready to reboot
ohci1394 0002:20:0e.0: enabling device (0000 -> 0002)
zd1211_USB_PACKAGE_READ_REGISTER: warning, restarting INT EP
zd1211_readl retry OK
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[40]
MMIO=[f5000000-f50007ff] Max Packet=[2048] IR/IT contexts=[8/8]
PA type: 2
Airoha AL2230S_RF
Overwrite CR157 = 0x0
Overwrite CR47 = 0x10019
zd1205_config: EEP(HWFeature)=0xF7D0
AllowedChannel = 00013fff
Region:0
zd1211_USB_PACKAGE_READ_REGISTER: warning, restarting INT EP
zd1211_readl retry OK
usbcore: registered new interface driver zd1211
I am able to do iwlist ath0 scanning, a list of acess point appears but
sometimes this fails.
iwlist ath0 scanning:
ath0 Scan completed :
Cell 01 - Address: 00:21:91:0E:0B:F7
ESSID:"adminWF10"
Mode:Master
Frequency=2.412 GHz (Channel 1)
Quality=46/100 Signal level=-74 dBm Noise
level=-96 dBm
Encryption key:off
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
48 Mb/s; 54 Mb/s
Extra:bcn_int=100
Cell 02 - Address: 00:1D:0F:D1:4D:D2
ESSID:"LGAA_P_CENTRAL_WF01"
Mode:Master
Frequency=2.437 GHz (Channel 6)
Quality=43/100 Signal level=-76 dBm Noise
level=-96 dBm
Encryption key:off
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
48 Mb/s; 54 Mb/s
Extra:bcn_int=100
Cell 03 - Address: 00:1B:11:87:A7:0C
ESSID:"ponto-acesso-mutsuo"
Mode:Master
Frequency=2.437 GHz (Channel 6)
Quality=43/100 Signal level=-76 dBm Noise
level=-96 dBm
Encryption key:off
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Extra:bcn_int=100
Scan again, it fails and works seemingly in an unknown manner.
iwlist ath0 scanning
ath0 Failed to read scan data : Resource temporarily unavailable
Some message in dmesg of relevance:
...
zd1211_USB_PACKAGE_READ_REGISTER: warning, restarting INT EP
zd1211_readl retry OK
zd1211_USB_PACKAGE_READ_REGISTER: warning, restarting INT EP
zd1211_readl retry OK
zd1211_USB_PACKAGE_READ_REGISTER: warning, restarting INT EP
zd1211_readl retry OK
zd1211_USB_PACKAGE_READ_REGISTER: warning, restarting INT EP
zd1211_readl retry OK
....(many times over)
and
1211_readl failed for 5 attempts...Very Serious<3>1211_readl failed for
5 attempts...Very Serious<3>1211_readl failed for 5 attempts...Very
Serious<3>1211_readl failed for 5 attempts...Very Serious<3>1211_readl
failed for 5 attempts...Very Serious<3>1211_readl failed for 5
attempts...Very Serious<3>1211_readl failed for 5 attempts...Very
Serious<3>1211_readl failed for 5 attempts...Very Serious<3>1211_readl
failed for 5 attempts...Very Serious<3>1211_readl failed for 5
attempts...Very Serious<3>1211_readl failed for 5 attempts...Very
Serious<3>1211_readl failed for 5 attempts...Very Serious<3>1211_readl
failed for 5 attempts...Very Serious<3>1211_readl failed for 5
attempts...Very Serious<3>1211_readl failed for 5 attempts...Very
Serious<7>zd1205_notify_disjoin_event
Giving up .... for now.
Regards,
Leonardo
On Sat, Sep 12, 2009 at 11:43 PM, Leonardo H. Souza Hamada
<[email protected]> wrote:
> Hi all,
>
> At this moment, after tweaking the zd1211rw code in kernel
> 2.6.31-gentoo, finally I am able to use the WLI-U2-KG54L wireless usb
> dongle on this old ibook.
>
> Browsing the source with a cross referencing tool
> (http://lxr.free-electrons.com) and making additional checking points, I
> could trace the issue as follow.
>
> The problem is that this device returns a regulatory region of 0x49,
> which is not defined in the zd1211rw tables. So the call
>
> r <http://lxr.free-electrons.com/ident?i=r> = zd_reg2alpha2 <http://lxr.free-electrons.com/ident?i=zd_reg2alpha2>(mac <http://lxr.free-electrons.com/ident?i=mac>->regdomain, alpha2);
>
> will fail the initialization process.
>
>
> Workaround:
>
> ----snip----
> int zd_mac_init_hw(struct ieee80211_hw *hw)
> {
> ...
> r = zd_read_regdomain(chip, &default_regdomain);
> /* A unknown regulatory of 0x49 will be set default to
> ZD_REGDOMAIN_FCC. */
> if (0x49 == default_regdomain)
> default_regdomain = ZD_REGDOMAIN_FCC;
> ...
> ----snip----
>
> The above code will force the default regulatry to be FCC code for this
> case. I think that this was the case in previous zd1211rw driver. What
> is the country code for 0x49 region? There is a better way?
>
>
> Thanks all,
>
> Phew!! Leonardo
The vendor driver has quite a lot more regdomain code defined, and
0x49 is apparently
ZD_Region_Japan_3 = 0x49,//G channel->ch1-13; A channel->8~16,34~46;
the rw driver code probably should set it to most restrictive than let
it fail...
On Mon, Sep 14, 2009 at 5:47 PM, Leonardo H. Souza Hamada
<[email protected]> wrote:
> <<<Disabling original zd1211rw in kernel configuration, recompiled
> kernel as instructed above, installed new kernel, reboot, many times
> until I got it right>>>
The patch isn't particularly version-specific - may have applied to
the kernel source itself...
> Results:
>
> dmesg seems ok. no errors.
No, I want to see dmesg - there should be something similiar to this?
cfg80211: Calling CRDA for country: GB
cfg80211: Regulatory domain changed to country: GB
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
(5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
> can do iwlist wlan0
>
> iwconfig wlan0 shows:
> IEEE 802.11bg Mode:Managed Access Point: Not-Associated
> Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
>
>
> I do not seem to be able to connect to a given access point so far. LED
> does not blink.
stay dark or stay lit?
Luis R. Rodriguez wrote:
> On Sun, Sep 13, 2009 at 8:41 PM, Hin-Tak Leung <[email protected]> wrote:
>
>> On Sun, Sep 13, 2009 at 11:13 AM, Hin-Tak Leung <[email protected]> wrote:
>>
>>> On Sat, Sep 12, 2009 at 11:43 PM, Leonardo H. Souza Hamada
>>> <[email protected]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> At this moment, after tweaking the zd1211rw code in kernel
>>>> 2.6.31-gentoo, finally I am able to use the WLI-U2-KG54L wireless usb
>>>> dongle on this old ibook.
>>>>
>>>> Browsing the source with a cross referencing tool
>>>> (http://lxr.free-electrons.com) and making additional checking points, I
>>>> could trace the issue as follow.
>>>>
>>>> The problem is that this device returns a regulatory region of 0x49,
>>>> which is not defined in the zd1211rw tables. So the call
>>>>
>>>> r <http://lxr.free-electrons.com/ident?i=r> = zd_reg2alpha2 <http://lxr.free-electrons.com/ident?i=zd_reg2alpha2>(mac <http://lxr.free-electrons.com/ident?i=mac>->regdomain, alpha2);
>>>>
>>>> will fail the initialization process.
>>>>
>>>>
>>>> Workaround:
>>>>
>>>> ----snip----
>>>> int zd_mac_init_hw(struct ieee80211_hw *hw)
>>>> {
>>>> ...
>>>> r = zd_read_regdomain(chip, &default_regdomain);
>>>> /* A unknown regulatory of 0x49 will be set default to
>>>> ZD_REGDOMAIN_FCC. */
>>>> if (0x49 == default_regdomain)
>>>> default_regdomain = ZD_REGDOMAIN_FCC;
>>>> ...
>>>> ----snip----
>>>>
>>>> The above code will force the default regulatry to be FCC code for this
>>>> case. I think that this was the case in previous zd1211rw driver. What
>>>> is the country code for 0x49 region? There is a better way?
>>>>
>>>>
>>>> Thanks all,
>>>>
>>>> Phew!! Leonardo
>>>>
>>> The vendor driver has quite a lot more regdomain code defined, and
>>> 0x49 is apparently
>>>
>>> ZD_Region_Japan_3 = 0x49,//G channel->ch1-13; A channel->8~16,34~46;
>>>
>>> the rw driver code probably should set it to most restrictive than let
>>> it fail...
>>>
>>>
>> Can you give this patch a try against a recent
>> wireless-testing/compat-wireless? I think this is the correct way to
>> do things.
>>
>> Here is the content of the patch for others who doesn't like
>> attachments - it just sets 0x49 as Japan.
>> ==============================
>> diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c
>> b/drivers/net/wireless/zd1211rw/zd_mac.c
>> index 6d66635..b0d32c4 100644
>> --- a/drivers/net/wireless/zd1211rw/zd_mac.c
>> +++ b/drivers/net/wireless/zd1211rw/zd_mac.c
>> @@ -42,6 +42,7 @@ static struct zd_reg_alpha2_map reg_alpha2_map[] = {
>> { ZD_REGDOMAIN_ETSI, "DE" }, /* Generic ETSI, use most restrictive */
>> { ZD_REGDOMAIN_JAPAN, "JP" },
>> { ZD_REGDOMAIN_JAPAN_ADD, "JP" },
>> + { ZD_REGDOMAIN_JAPAN_3, "JP" },
>> { ZD_REGDOMAIN_SPAIN, "ES" },
>> { ZD_REGDOMAIN_FRANCE, "FR" },
>> };
>> diff --git a/drivers/net/wireless/zd1211rw/zd_mac.h
>> b/drivers/net/wireless/zd1211rw/zd_mac.h
>> index 7c27591..9701935 100644
>> --- a/drivers/net/wireless/zd1211rw/zd_mac.h
>> +++ b/drivers/net/wireless/zd1211rw/zd_mac.h
>> @@ -193,6 +193,7 @@ struct zd_mac {
>> #define ZD_REGDOMAIN_FRANCE 0x32
>> #define ZD_REGDOMAIN_JAPAN_ADD 0x40
>> #define ZD_REGDOMAIN_JAPAN 0x41
>> +#define ZD_REGDOMAIN_JAPAN_3 0x49
>>
>
> FWIW, this does seem right.
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
*
Ok, got *compat-wireless-2.6.tar.bz2
<http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2.6.tar.bz2>*
"bleeding edge compat-wireless" from* here:
http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2.6.tar.bz2
Steps done, so so:
tar -xjf compat-wireless-2.6.tar.bz2
cd compat-wireless-2009-09-14/
cp -v ../zd1211rw_jp3.diff .
`../zd1211rw_jp3.diff' -> `./zd1211rw_jp3.diff'
patch -p1 < zd1211rw_jp3.diff
patching file drivers/net/wireless/zd1211rw/zd_mac.c
patching file drivers/net/wireless/zd1211rw/zd_mac.h
./scripts/driver-select zd1211rw
Processing new driver-select request...
Backing up makefile: Makefile.bk
Backing up makefile: drivers/net/wireless/Makefile.bk
Backing up makefile: net/wireless/Makefile.bk
Backing up makefile: drivers/ssb/Makefile.bk
Backing up makefile: drivers/net/usb/Makefile.bk
Backing up makefile: drivers/misc/eeprom/Makefile.bk
make
/home/leo/compat-wireless-2009-09-14/config.mk:17: *** "ERROR: you have
MAC80211 compiled into the kernel, CONFIG_MAC80211=y, as such you cannot
replace its mac80211 driver. You need this set to CONFIG_MAC80211=m. If
you are using Fedora upgrade your kernel as later version should this
set as modular. For further information on Fedora see
https://bugzilla.redhat.com/show_bug.cgi?id=470143. If you are using
your own kernel recompile it and make mac80211 modular". Pare.
<<<Disabling original zd1211rw in kernel configuration, recompiled
kernel as instructed above, installed new kernel, reboot, many times
until I got it right>>>
Results:
dmesg seems ok. no errors.
can do iwlist wlan0
iwconfig wlan0 shows:
IEEE 802.11bg Mode:Managed Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
I do not seem to be able to connect to a given access point so far. LED
does not blink.
It can be that there is a query on the new values against other. Just a
guess.
Regards,
Leonardo