Thread: [Madwifi-users] Fast channel switching
Status: Beta
Brought to you by:
otaku
Menu
▾
▴
madwifi-users
|
From: vishal11 <vis...@gm...> - 2010-02-16 18:08:45
|
Hi All Iam a student and am trying to incorporate fast channel switching in madwifi for my project. Currently as measured the time for execution of the function ath_set_channel for madwifi_0.9.4_trunkr3314 is about 20ms (as tested on Mikrotik RB433AH board running openwrt kamikaze v8.09). However for the later releases with HAL code (madwifi_0.9.4_r3980 and later), we have measured the execution time for the same function to be about 4-5ms. Also we have noticed that there is a function for AR5212 chipset, ar5212ChannelChange(), whose execution time as measured is about 500 microseconds. However our problem is that we are not able to make madwifi_0.9.4_r3980 or later release (till latest r4119) work on Mikrotik RB433AH boards (employing Openwrt kamikaze v8.09). We have been able to compile the latest madwifi release on Openwrt, but when modules load, the following error message keeps appearing wifi0 ath_fatal_tasklet hardware error resetting Morever we have already incorporated quite a few changes in madwifi_0.9.4_trunkr3314 and it will be difficult for us to port these changes to latest madwifi release. So would it be possible to make use of the function ar5212ChannelChange() in madwifi_0.9.4_trunkr3314. What changes will we need to make for that?? We tried to implement the function ar5212ChannelChange() in madwifi_0.9.4_trunkr3314 ourselves, but have not been successfull so far. Any help or suggestion would be greatly appreciated. Thanks Vishal -- View this message in context: http://n2.nabble.com/Fast-channel-switching-tp4581780p4581780.html Sent from the Madwifi Users mailing list archive at Nabble.com. |
|
From: lorenzo863 <lor...@gm...> - 2013-02-04 15:49:30
|
Hi guys. I'm an italian student and this is the first time I use madwifi drivers. My intention is to add, to the trunk version of the driver, a function that allow to opportunely switch the channel if the level of noise is too high, (beyond a certain threshold). Do you think it could be possible? (If yes) Do it without resetting the hardware? Thank you in advance. Regards, Lorenzo -- View this message in context: http://madwifi-users.20070.n2.nabble.com/Fast-channel-switching-tp7574648.html Sent from the Madwifi Users mailing list archive at Nabble.com. |
|
From: Wright, B. <Bre...@co...> - 2013-02-05 00:35:24
|
Hi Lorenzo, You may want to consider modifying mac80211 and/or ath5k/ath9k as madwifi is effectively dead. As for what you want to do, I think the Atheros hardware effectively has to be reset upon channel change, but it is very quick. You might want to consider some other metrics other than just channel noise, as in real world situations the type of interference that you will encounter will not necessarily have any impact on the channel noise level. Channel utilization would be a better metric in my opinion. This would include the amount of time the channel is busy to CCA (clear channel assessment) and receive. The newer mac80211 and ath drivers support access to this information. Brett > -----Original Message----- > From: lorenzo863 [mailto:lor...@gm...] > Sent: Tuesday, 5 February 2013 1:49 AM > To: mad...@li... > Subject: [Madwifi-users] Fast channel switching > > Hi guys. > I'm an italian student and this is the first time I use madwifi drivers. > My intention is to add, to the trunk version of the driver, a function that > allow to opportunely switch the channel if the level of noise is too high, > (beyond a certain threshold). > Do you think it could be possible? > (If yes) Do it without resetting the hardware? > > Thank you in advance. > > Regards, > > Lorenzo > > > > -- > View this message in context: http://madwifi- > users.20070.n2.nabble.com/Fast-channel-switching-tp7574648.html > Sent from the Madwifi Users mailing list archive at Nabble.com. > > ------------------------------------------------------------------------ ------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics Download AppDynamics Lite > for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > Madwifi-users mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-users |
|
From: lorenzo863 <lor...@gm...> - 2013-02-05 08:27:28
|
First of all, thank you for your replies.
/>>You may want to consider modifying mac80211 and/or ath5k/ath9k as
madwifi is effectively dead/
I have partially implemented TDMA on madwifi: do you think it could be
difficult to implement on ath5k?
The problem is that I have not enough time to spend to study how ath5k
works.
/>>Channel utilization would be a better metric in my opinion./
Is it impossible to access to this information by using Madwifi drivers?
Also with the trunked version?
Regards,
Lorenzo
--
View this message in context: http://madwifi-users.20070.n2.nabble.com/Fast-channel-switching-tp7574648p7574651.html
Sent from the Madwifi Users mailing list archive at Nabble.com.
|
|
From: Brian P. <bpr...@co...> - 2013-02-04 19:02:30
|
I would strongly suggest doing your work with ath5k or ath9k. The level of community help you'll get with those drivers will be much higher. On Mon, Feb 4, 2013 at 10:49 AM, lorenzo863 <lor...@gm...> wrote: > Hi guys. > I'm an italian student and this is the first time I use madwifi drivers. > My intention is to add, to the trunk version of the driver, a function that > allow to opportunely switch the channel if the level of noise is too high, > (beyond a certain threshold). > Do you think it could be possible? > (If yes) Do it without resetting the hardware? > > Thank you in advance. > > Regards, > > Lorenzo > > > > -- > View this message in context: > http://madwifi-users.20070.n2.nabble.com/Fast-channel-switching-tp7574648.html > Sent from the Madwifi Users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > Madwifi-users mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-users > -- -- http://www.connectify.me/ This email message is for the sole use of the intended recipient(s) and may contain Connectify confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message. |
|
From: Pavel R. <pr...@gn...> - 2010-02-16 22:21:15
|
On Tue, 2010-02-16 at 10:08 -0800, vishal11 wrote: > Hi All > > Iam a student and am trying to incorporate fast channel switching in madwifi > for my project. Currently as measured the time for execution of the function > ath_set_channel for madwifi_0.9.4_trunkr3314 is about 20ms (as tested on > Mikrotik RB433AH board running openwrt kamikaze v8.09). However for the > later releases with HAL code (madwifi_0.9.4_r3980 and later), we have > measured the execution time for the same function to be about 4-5ms. Also we > have noticed that there is a function for AR5212 chipset, > ar5212ChannelChange(), whose execution time as measured is about 500 > microseconds. > > However our problem is that we are not able to make madwifi_0.9.4_r3980 or > later release (till latest r4119) work on Mikrotik RB433AH boards (employing > Openwrt kamikaze v8.09). We have been able to compile the latest madwifi > release on Openwrt, but when modules load, the following error message keeps > appearing > > wifi0 ath_fatal_tasklet hardware error resetting I suggest that you do your work on free code, such as madwifi trunk or better yet, on ath5k. I assume you use miniPCI cards and don't need AHB support. HAL in MadWifi 0.9.4 is essentially a black box. > Morever we have already incorporated quite a few changes in > madwifi_0.9.4_trunkr3314 and it will be difficult for us to port these > changes to latest madwifi release. So would it be possible to make use of > the function ar5212ChannelChange() in madwifi_0.9.4_trunkr3314. What changes > will we need to make for that?? We tried to implement the function > ar5212ChannelChange() in madwifi_0.9.4_trunkr3314 ourselves, but have not > been successfull so far. > > Any help or suggestion would be greatly appreciated. I doubt anyone would want to debug problems in non-free HAL at this time. -- Regards, Pavel Roskin |
|
From: Vishal S. <vis...@gm...> - 2010-02-17 05:40:43
|
On Wed, Feb 17, 2010 at 3:50 AM, Pavel Roskin <pr...@gn...> wrote: > On Tue, 2010-02-16 at 10:08 -0800, vishal11 wrote: > > Hi All > > > > Iam a student and am trying to incorporate fast channel switching in > madwifi > > for my project. Currently as measured the time for execution of the > function > > ath_set_channel for madwifi_0.9.4_trunkr3314 is about 20ms (as tested on > > Mikrotik RB433AH board running openwrt kamikaze v8.09). However for the > > later releases with HAL code (madwifi_0.9.4_r3980 and later), we have > > measured the execution time for the same function to be about 4-5ms. Also > we > > have noticed that there is a function for AR5212 chipset, > > ar5212ChannelChange(), whose execution time as measured is about 500 > > microseconds. > > > > However our problem is that we are not able to make madwifi_0.9.4_r3980 > or > > later release (till latest r4119) work on Mikrotik RB433AH boards > (employing > > Openwrt kamikaze v8.09). We have been able to compile the latest madwifi > > release on Openwrt, but when modules load, the following error message > keeps > > appearing > > > > wifi0 ath_fatal_tasklet hardware error resetting > > I suggest that you do your work on free code, such as madwifi trunk or > better yet, on ath5k. I assume you use miniPCI cards and don't need AHB > support. > > Ok fine we can work on the madwifi trunk version which comes with HAL code, but we are not able to run it on Mikrotik boards employing Openwrt. The hardware and software configuration that we are employing is miniPCI Ubiquiti SR2 cards based on AR5212 chipset on Mikrotik RB433AH boards. The OS that we are using in Openwrt kamikaze v8.09 with linux kernel 2.6.26.5 and we tried with madwifi_0.9.4r3980 till madwifi_0.9.4r4119. As mentioned when the modules load, the following error keeps appearing wifi0 ath_fatal_tasklet hardware error resetting I did apply the following patch https://madwifi-project.org/ticket/2322 , but to no avail. Could you point out as to what the problem could be?? If you need me to provide any other debug information please do let me know. > HAL in MadWifi 0.9.4 is essentially a black box. > > > Morever we have already incorporated quite a few changes in > > madwifi_0.9.4_trunkr3314 and it will be difficult for us to port these > > changes to latest madwifi release. So would it be possible to make use of > > the function ar5212ChannelChange() in madwifi_0.9.4_trunkr3314. What > changes > > will we need to make for that?? We tried to implement the function > > ar5212ChannelChange() in madwifi_0.9.4_trunkr3314 ourselves, but have not > > been successfull so far. > > > > Any help or suggestion would be greatly appreciated. > > I doubt anyone would want to debug problems in non-free HAL at this > time. > > -- > Regards, > Pavel Roskin > |
|
From: Pavel R. <pr...@gn...> - 2010-02-17 17:38:38
|
On Wed, 2010-02-17 at 11:10 +0530, Vishal Sevani wrote: > Ok fine we can work on the madwifi trunk version which comes with HAL > code, but we are not able to run it on Mikrotik boards employing > Openwrt. The hardware and software configuration that we are employing > is miniPCI Ubiquiti SR2 cards based on AR5212 chipset on Mikrotik > RB433AH boards. The OS that we are using in Openwrt kamikaze v8.09 > with linux kernel 2.6.26.5 and we tried with madwifi_0.9.4r3980 till > madwifi_0.9.4r4119. The latest compat-wireless (only the 2.6.32 edition for now) should compile for Linux 2.6.26 as long as you only select Atheros drivers. http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/ I do realize to switching from MadWifi to ath5k is a bigger deal than switching between MadWifi branches. > As mentioned when the modules load, the following error keeps > appearing > > wifi0 ath_fatal_tasklet hardware error resetting > > I did apply the following patch > https://madwifi-project.org/ticket/2322 , but to no avail. Could you > point out as to what the problem could be?? If you need me to provide > any other debug information please do let me know. I'll appreciate if you post your results to the ticket. So far there have been no test results for that patch at all. -- Regards, Pavel Roskin |
|
From: Vishal S. <vis...@gm...> - 2010-02-19 09:47:45
|
On Wed, Feb 17, 2010 at 11:08 PM, Pavel Roskin <pr...@gn...> wrote: > On Wed, 2010-02-17 at 11:10 +0530, Vishal Sevani wrote: > > > Ok fine we can work on the madwifi trunk version which comes with HAL > > code, but we are not able to run it on Mikrotik boards employing > > Openwrt. The hardware and software configuration that we are employing > > is miniPCI Ubiquiti SR2 cards based on AR5212 chipset on Mikrotik > > RB433AH boards. The OS that we are using in Openwrt kamikaze v8.09 > > with linux kernel 2.6.26.5 and we tried with madwifi_0.9.4r3980 till > > madwifi_0.9.4r4119. > > The latest compat-wireless (only the 2.6.32 edition for now) should > compile for Linux 2.6.26 as long as you only select Atheros drivers. > http://www.orbit-lab.org/kernel/compat-wireless-2.6-stable/v2.6.32/ > > I do realize to switching from MadWifi to ath5k is a bigger deal than > switching between MadWifi branches. > The thing is that we intend to implement time divsion multiple access in WiFi with support for multi-channel operation. We have already implemented time synchronization mechanism in madwifi, which took us considerable effort. Now shifting to ath5k will again take up time as we are not conversant with ath5k code. > > > As mentioned when the modules load, the following error keeps > > appearing > > > > wifi0 ath_fatal_tasklet hardware error resetting > > > > I did apply the following patch > > https://madwifi-project.org/ticket/2322 , but to no avail. Could you > > point out as to what the problem could be?? If you need me to provide > > any other debug information please do let me know. > > I'll appreciate if you post your results to the ticket. So far there > have been no test results for that patch at all. > > Yeah I have posted my experience in the following ticket. https://madwifi-project.org/ticket/2359 Yesterday again I tried with latest release of Openwrt Kamikaze ie. v8.09.2, but still I get the same problem. But the madwifi code works properly on IBM latop running Ubuntu with Linux kernel 2.6.24-23. So I guess it is the issue with Openwrt or the hardware ie. AR71xx boards. Has the latest code been tested on Openwrt and Ar71xx boards?? Thanks Vishal > -- > Regards, > Pavel Roskin > |
|
From: Pavel R. <pr...@gn...> - 2010-02-19 23:30:21
|
On Fri, 2010-02-19 at 15:17 +0530, Vishal Sevani wrote: > > I did apply the following patch > > https://madwifi-project.org/ticket/2322 , but to no avail. > Could you > > point out as to what the problem could be?? If you need me > to provide > > any other debug information please do let me know. > > > I'll appreciate if you post your results to the ticket. So > far there > have been no test results for that patch at all. > > Yeah I have posted my experience in the following ticket. > https://madwifi-project.org/ticket/2359 I actually I meant that you would report a negative result with the patch in #2322. But it looks like the problems are different. > Yesterday again I tried with latest release of Openwrt Kamikaze ie. > v8.09.2, but still I get the same problem. But the madwifi code works > properly on IBM latop running Ubuntu with Linux kernel 2.6.24-23. So I > guess it is the issue with Openwrt or the hardware ie. AR71xx boards. > Has the latest code been tested on Openwrt and Ar71xx boards?? I'm not aware of it. -- Regards, Pavel Roskin |
|
From: Vishal S. <vis...@gm...> - 2010-02-22 08:40:11
|
On Sat, Feb 20, 2010 at 5:00 AM, Pavel Roskin <pr...@gn...> wrote: > On Fri, 2010-02-19 at 15:17 +0530, Vishal Sevani wrote: > > > > I did apply the following patch > > > https://madwifi-project.org/ticket/2322 , but to no avail. > > Could you > > > point out as to what the problem could be?? If you need me > > to provide > > > any other debug information please do let me know. > > > > > > I'll appreciate if you post your results to the ticket. So > > far there > > have been no test results for that patch at all. > > > > Yeah I have posted my experience in the following ticket. > > https://madwifi-project.org/ticket/2359 > > I actually I meant that you would report a negative result with the > patch in #2322. But it looks like the problems are different. > > Yeah it seems more of a hardware issue with AR71xx borad, (or issue with Openwrt) as pointed out by ne...@pa... in his comment following yours in the ticket #2359. If Iam correct, it is happening because the value in reg AR_ISR corresponding to flag AR_ISR_HIUERR is being set, which is for unexpected bus error. As mentioned in the following post http://n2.nabble.com/fatal-interrupt-td3225930.html, it is beacuse the following bit, AR_ISR_S2_MCABT (for master cycle abort) is being set. Iam clueless as to what could be causing this master cycle abort problem and how should I go about debugging it. Could you please provide any pointers as to how I can rectify this problem. > > Yesterday again I tried with latest release of Openwrt Kamikaze ie. > > v8.09.2, but still I get the same problem. But the madwifi code works > > properly on IBM latop running Ubuntu with Linux kernel 2.6.24-23. So I > > guess it is the issue with Openwrt or the hardware ie. AR71xx boards. > > Has the latest code been tested on Openwrt and Ar71xx boards?? > > I'm not aware of it. > > -- > Regards, > Pavel Roskin > |
|
From: IVAN K. <200...@ma...> - 2010-02-22 16:49:32
|
void ar5212SetChannel5112work2192(UINT32 freq)
{
/* Step 5 MHz */
UINT32 ii,channelSelect;
volatile UINT32 *hard_reg;
channelSelect = ((freq - 672) * 2 - 3040)/10;
channelSelect = (channelSelect << 2) & 0xff;
channelSelect = ath_hal_reverseBits(channelSelect, 8);
channelSelect = (channelSelect << 4) | 0x1005;
hard_reg = (void*)0xB8510024; *hard_reg = 0x0;
sysUDelayFlash (0x3E8);
hard_reg = (void*)0xb851981c; *hard_reg = 0x0;
sysUDelayFlash (0xA);
hard_reg = (void*)0xb851989C; *hard_reg = (channelSelect & 0xff);
channelSelect = (channelSelect >> 8) & 0x7f;
hard_reg = (void*)0xb85198D8; *hard_reg = channelSelect;
sysUDelayFlash (0xA);
hard_reg = (void*)0xb851981c; *hard_reg = 0x1;
sysUDelayFlash (0x64);
hard_reg = (void*)0xb8519860;
*hard_reg = *hard_reg |0x2;
channelSelect = 0x2;
for (ii=0; (ii< 0x3FFFE) && channelSelect ;ii++)channelSelect = *hard_reg & 0x2;
hard_reg = (void*)0xB8510024; *hard_reg = 0x1;
}
-----Original Message-----
From: Vishal Sevani <vis...@gm...>
To: mad...@li...
Date: Mon, 22 Feb 2010 14:10:04 +0530
Subject: Re: [Madwifi-users] Fast channel switching
> On Sat, Feb 20, 2010 at 5:00 AM, Pavel Roskin <pr...@gn...> wrote:
>
> > On Fri, 2010-02-19 at 15:17 +0530, Vishal Sevani wrote:
> >
> > > > I did apply the following patch
> > > > https://madwifi-project.org/ticket/2322 , but to no avail.
> > > Could you
> > > > point out as to what the problem could be?? If you need me
> > > to provide
> > > > any other debug information please do let me know.
> > >
> > >
> > > I'll appreciate if you post your results to the ticket. So
> > > far there
> > > have been no test results for that patch at all.
> > >
> > > Yeah I have posted my experience in the following ticket.
> > > https://madwifi-project.org/ticket/2359
> >
> > I actually I meant that you would report a negative result with the
> > patch in #2322. But it looks like the problems are different.
> >
> > Yeah it seems more of a hardware issue with AR71xx borad, (or issue with
> Openwrt) as pointed out by ne...@pa... in his comment following yours
> in the ticket #2359. If Iam correct, it is happening because the value in
> reg AR_ISR corresponding to flag AR_ISR_HIUERR is being set, which is for
> unexpected bus error. As mentioned in the following post
> http://n2.nabble.com/fatal-interrupt-td3225930.html, it is beacuse the
> following bit, AR_ISR_S2_MCABT (for master cycle abort) is being set.
>
> Iam clueless as to what could be causing this master cycle abort problem and
> how should I go about debugging it. Could you please provide any pointers as
> to how I can rectify this problem.
>
>
> > > Yesterday again I tried with latest release of Openwrt Kamikaze ie.
> > > v8.09.2, but still I get the same problem. But the madwifi code works
> > > properly on IBM latop running Ubuntu with Linux kernel 2.6.24-23. So I
> > > guess it is the issue with Openwrt or the hardware ie. AR71xx boards.
> > > Has the latest code been tested on Openwrt and Ar71xx boards??
> >
> > I'm not aware of it.
> >
> > --
> > Regards,
> > Pavel Roskin
> >
>
> ------------------------------------------------------------------------------
> Download Intel Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Madwifi-users mailing list
> Mad...@li...
> https://lists.sourceforge.net/lists/listinfo/madwifi-users
>
>
|
|
From: Vishal S. <vis...@gm...> - 2010-02-23 06:35:13
|
On Mon, Feb 22, 2010 at 10:19 PM, IVAN KORSHUN <200...@ma...> wrote:
> void ar5212SetChannel5112work2192(UINT32 freq)
> {
> /* Step 5 MHz */
> UINT32 ii,channelSelect;
> volatile UINT32 *hard_reg;
>
> channelSelect = ((freq - 672) * 2 - 3040)/10;
> channelSelect = (channelSelect << 2) & 0xff;
> channelSelect = ath_hal_reverseBits(channelSelect, 8);
>
>
> channelSelect = (channelSelect << 4) | 0x1005;
>
> hard_reg = (void*)0xB8510024; *hard_reg = 0x0;
> sysUDelayFlash (0x3E8);
> hard_reg = (void*)0xb851981c; *hard_reg = 0x0;
> sysUDelayFlash (0xA);
> hard_reg = (void*)0xb851989C; *hard_reg = (channelSelect & 0xff);
>
> channelSelect = (channelSelect >> 8) & 0x7f;
> hard_reg = (void*)0xb85198D8; *hard_reg = channelSelect;
> sysUDelayFlash (0xA);
> hard_reg = (void*)0xb851981c; *hard_reg = 0x1;
> sysUDelayFlash (0x64);
> hard_reg = (void*)0xb8519860;
> *hard_reg = *hard_reg |0x2;
> channelSelect = 0x2;
> for (ii=0; (ii< 0x3FFFE) && channelSelect ;ii++)channelSelect =
> *hard_reg & 0x2;
>
> hard_reg = (void*)0xB8510024; *hard_reg = 0x1;
>
> }
>
Hi Ivan
Do you intend to suggest that I can call this function directly for
switching the frequency?? If so could you please explain as to what the
function does. You are setting the values for the variable, hard_reg and
channelSelect, but dont you need to set these values in the register so that
the hardware actually changes the channel?
Also what is the definition for the function, sysUDelayFlash () since it is
not available in the madwifi code.
Thanks
Vishal
>
> -----Original Message-----
> From: Vishal Sevani <vis...@gm...>
> To: mad...@li...
> Date: Mon, 22 Feb 2010 14:10:04 +0530
> Subject: Re: [Madwifi-users] Fast channel switching
>
> > On Sat, Feb 20, 2010 at 5:00 AM, Pavel Roskin <pr...@gn...> wrote:
> >
> > > On Fri, 2010-02-19 at 15:17 +0530, Vishal Sevani wrote:
> > >
> > > > > I did apply the following patch
> > > > > https://madwifi-project.org/ticket/2322 , but to no avail.
> > > > Could you
> > > > > point out as to what the problem could be?? If you need me
> > > > to provide
> > > > > any other debug information please do let me know.
> > > >
> > > >
> > > > I'll appreciate if you post your results to the ticket. So
> > > > far there
> > > > have been no test results for that patch at all.
> > > >
> > > > Yeah I have posted my experience in the following ticket.
> > > > https://madwifi-project.org/ticket/2359
> > >
> > > I actually I meant that you would report a negative result with the
> > > patch in #2322. But it looks like the problems are different.
> > >
> > > Yeah it seems more of a hardware issue with AR71xx borad, (or issue
> with
> > Openwrt) as pointed out by ne...@pa... in his comment following
> yours
> > in the ticket #2359. If Iam correct, it is happening because the value in
> > reg AR_ISR corresponding to flag AR_ISR_HIUERR is being set, which is for
> > unexpected bus error. As mentioned in the following post
> > http://n2.nabble.com/fatal-interrupt-td3225930.html, it is beacuse the
> > following bit, AR_ISR_S2_MCABT (for master cycle abort) is being set.
> >
> > Iam clueless as to what could be causing this master cycle abort problem
> and
> > how should I go about debugging it. Could you please provide any pointers
> as
> > to how I can rectify this problem.
> >
> >
> > > > Yesterday again I tried with latest release of Openwrt Kamikaze ie.
> > > > v8.09.2, but still I get the same problem. But the madwifi code works
> > > > properly on IBM latop running Ubuntu with Linux kernel 2.6.24-23. So
> I
> > > > guess it is the issue with Openwrt or the hardware ie. AR71xx boards.
> > > > Has the latest code been tested on Openwrt and Ar71xx boards??
> > >
> > > I'm not aware of it.
> > >
> > > --
> > > Regards,
> > > Pavel Roskin
> > >
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Madwifi-users mailing list
> > Mad...@li...
> > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> >
> >
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Madwifi-users mailing list
> Mad...@li...
> https://lists.sourceforge.net/lists/listinfo/madwifi-users
>
|
|
From: IVAN K. <200...@ma...> - 2010-02-23 07:57:22
|
sysUDelayFlash its ath_hal_delay(int n) /* Delay n microseconds */
I use non Linux OS ...
ar5212SetChannel5112work2192(2192); //set freq 2192 MHz
ar5212SetChannel5112work2192(2195); //set freq 2195 MHz
...
ar5212SetChannel5112work2192(2512); //set freq 2512 MHz
and hard_reg ...
0xB8510024 its AR_IER 0x0024 /* MAC Interrupt enable register */
0xb851981c its AR_PHY_ACTIVE 0x981C /* activation register */
0xb8519860 its AR_PHY_AGC_CONTROL 0x9860 /* chip calibration and noise floor setting */
0xb851989C & 0xb85198D8 its regs for internal use ...
-----Original Message-----
From: Vishal Sevani <vis...@gm...>
To: mad...@li...
Date: Tue, 23 Feb 2010 12:05:05 +0530
Subject: Re: [Madwifi-users] Fast channel switching
> On Mon, Feb 22, 2010 at 10:19 PM, IVAN KORSHUN <200...@ma...> wrote:
>
> > void ar5212SetChannel5112work2192(UINT32 freq)
> > {
> > /* Step 5 MHz */
> > UINT32 ii,channelSelect;
> > volatile UINT32 *hard_reg;
> >
> > channelSelect = ((freq - 672) * 2 - 3040)/10;
> > channelSelect = (channelSelect << 2) & 0xff;
> > channelSelect = ath_hal_reverseBits(channelSelect, 8);
> >
> >
> > channelSelect = (channelSelect << 4) | 0x1005;
> >
> > hard_reg = (void*)0xB8510024; *hard_reg = 0x0;
> > sysUDelayFlash (0x3E8);
> > hard_reg = (void*)0xb851981c; *hard_reg = 0x0;
> > sysUDelayFlash (0xA);
> > hard_reg = (void*)0xb851989C; *hard_reg = (channelSelect & 0xff);
> >
> > channelSelect = (channelSelect >> 8) & 0x7f;
> > hard_reg = (void*)0xb85198D8; *hard_reg = channelSelect;
> > sysUDelayFlash (0xA);
> > hard_reg = (void*)0xb851981c; *hard_reg = 0x1;
> > sysUDelayFlash (0x64);
> > hard_reg = (void*)0xb8519860;
> > *hard_reg = *hard_reg |0x2;
> > channelSelect = 0x2;
> > for (ii=0; (ii< 0x3FFFE) && channelSelect ;ii++)channelSelect =
> > *hard_reg & 0x2;
> >
> > hard_reg = (void*)0xB8510024; *hard_reg = 0x1;
> >
> > }
> >
>
> Hi Ivan
>
> Do you intend to suggest that I can call this function directly for
> switching the frequency?? If so could you please explain as to what the
> function does. You are setting the values for the variable, hard_reg and
> channelSelect, but dont you need to set these values in the register so that
> the hardware actually changes the channel?
>
> Also what is the definition for the function, sysUDelayFlash () since it is
> not available in the madwifi code.
>
> Thanks
> Vishal
>
> >
> > -----Original Message-----
> > From: Vishal Sevani <vis...@gm...>
> > To: mad...@li...
> > Date: Mon, 22 Feb 2010 14:10:04 +0530
> > Subject: Re: [Madwifi-users] Fast channel switching
> >
> > > On Sat, Feb 20, 2010 at 5:00 AM, Pavel Roskin <pr...@gn...> wrote:
> > >
> > > > On Fri, 2010-02-19 at 15:17 +0530, Vishal Sevani wrote:
> > > >
> > > > > > I did apply the following patch
> > > > > > https://madwifi-project.org/ticket/2322 , but to no avail.
> > > > > Could you
> > > > > > point out as to what the problem could be?? If you need me
> > > > > to provide
> > > > > > any other debug information please do let me know.
> > > > >
> > > > >
> > > > > I'll appreciate if you post your results to the ticket. So
> > > > > far there
> > > > > have been no test results for that patch at all.
> > > > >
> > > > > Yeah I have posted my experience in the following ticket.
> > > > > https://madwifi-project.org/ticket/2359
> > > >
> > > > I actually I meant that you would report a negative result with the
> > > > patch in #2322. But it looks like the problems are different.
> > > >
> > > > Yeah it seems more of a hardware issue with AR71xx borad, (or issue
> > with
> > > Openwrt) as pointed out by ne...@pa... in his comment following
> > yours
> > > in the ticket #2359. If Iam correct, it is happening because the value in
> > > reg AR_ISR corresponding to flag AR_ISR_HIUERR is being set, which is for
> > > unexpected bus error. As mentioned in the following post
> > > http://n2.nabble.com/fatal-interrupt-td3225930.html, it is beacuse the
> > > following bit, AR_ISR_S2_MCABT (for master cycle abort) is being set.
> > >
> > > Iam clueless as to what could be causing this master cycle abort problem
> > and
> > > how should I go about debugging it. Could you please provide any pointers
> > as
> > > to how I can rectify this problem.
> > >
> > >
> > > > > Yesterday again I tried with latest release of Openwrt Kamikaze ie.
> > > > > v8.09.2, but still I get the same problem. But the madwifi code works
> > > > > properly on IBM latop running Ubuntu with Linux kernel 2.6.24-23. So
> > I
> > > > > guess it is the issue with Openwrt or the hardware ie. AR71xx boards.
> > > > > Has the latest code been tested on Openwrt and Ar71xx boards??
> > > >
> > > > I'm not aware of it.
> > > >
> > > > --
> > > > Regards,
> > > > Pavel Roskin
> > > >
> > >
> > >
> > ------------------------------------------------------------------------------
> > > Download Intel Parallel Studio Eval
> > > Try the new software tools for yourself. Speed compiling, find bugs
> > > proactively, and fine-tune applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > Madwifi-users mailing list
> > > Mad...@li...
> > > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> > >
> > >
> >
> >
> > ------------------------------------------------------------------------------
> > Download Intel Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Madwifi-users mailing list
> > Mad...@li...
> > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> >
>
> ------------------------------------------------------------------------------
> Download Intel Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Madwifi-users mailing list
> Mad...@li...
> https://lists.sourceforge.net/lists/listinfo/madwifi-users
>
>
|
|
From: Vishal S. <vis...@gm...> - 2010-02-24 08:19:21
|
Hi Ivan
Thanks a lot for the help. The function seems to be working, although I had
to make few changes. If I used the addess, 0xb8510024 for AR_IER it was
giving segmentation fault. However it did work with address 0x0024 (likewise
for other registers too). But although the frequency does get changed, it
does not get reflected in iwconfig command. For it I guess I will have to
set the member variable ic_curchan of variable ic (of type ieee80211com),
which Iam trying to figure out.
However one of the other issues is that this function is taking about 30ms
for switching the channel (I have tested it on x86 based IBM laptop).
Whereas we need a channel switching functionality of the order of
microseconds (preferably around 500 microseconds if possible). On analyzing
your function I observed that following for loop
for (ii=0; (ii< 0x3FFFE) && channelSelect ;ii++)channelSelect =*hard_reg &
0x2;
takes about 30ms. Although in place of this for loop I put a delay of about
100 microsecond and it does seem to work (though I have to test thouroughly
as to whether any packets are getting lost). Also Iam trying to figure the
optimal values for the different delays that you have called in your
function.
Could you please let me know as to on what basis have you come up with these
different values of delay (ie. 0x3E8, 0xA, 0x64, and the for loop), as it
would help me in optimizing these values for my hardware.
Thanks
Vishal
On Tue, Feb 23, 2010 at 1:27 PM, IVAN KORSHUN <200...@ma...> wrote:
> sysUDelayFlash its ath_hal_delay(int n) /* Delay n microseconds */
> I use non Linux OS ...
>
> ar5212SetChannel5112work2192(2192); //set freq 2192 MHz
> ar5212SetChannel5112work2192(2195); //set freq 2195 MHz
> ...
> ar5212SetChannel5112work2192(2512); //set freq 2512 MHz
>
> and hard_reg ...
> 0xB8510024 its AR_IER 0x0024 /* MAC Interrupt enable
> register */
> 0xb851981c its AR_PHY_ACTIVE 0x981C /* activation register */
> 0xb8519860 its AR_PHY_AGC_CONTROL 0x9860 /* chip calibration and
> noise floor setting */
>
> 0xb851989C & 0xb85198D8 its regs for internal use ...
>
>
> -----Original Message-----
> From: Vishal Sevani <vis...@gm...>
> To: mad...@li...
> Date: Tue, 23 Feb 2010 12:05:05 +0530
> Subject: Re: [Madwifi-users] Fast channel switching
>
> > On Mon, Feb 22, 2010 at 10:19 PM, IVAN KORSHUN <200...@ma...>
> wrote:
> >
> > > void ar5212SetChannel5112work2192(UINT32 freq)
> > > {
> > > /* Step 5 MHz */
> > > UINT32 ii,channelSelect;
> > > volatile UINT32 *hard_reg;
> > >
> > > channelSelect = ((freq - 672) * 2 - 3040)/10;
> > > channelSelect = (channelSelect << 2) & 0xff;
> > > channelSelect = ath_hal_reverseBits(channelSelect, 8);
> > >
> > >
> > > channelSelect = (channelSelect << 4) | 0x1005;
> > >
> > > hard_reg = (void*)0xB8510024; *hard_reg = 0x0;
> > > sysUDelayFlash (0x3E8);
> > > hard_reg = (void*)0xb851981c; *hard_reg = 0x0;
> > > sysUDelayFlash (0xA);
> > > hard_reg = (void*)0xb851989C; *hard_reg = (channelSelect &
> 0xff);
> > >
> > > channelSelect = (channelSelect >> 8) & 0x7f;
> > > hard_reg = (void*)0xb85198D8; *hard_reg = channelSelect;
> > > sysUDelayFlash (0xA);
> > > hard_reg = (void*)0xb851981c; *hard_reg = 0x1;
> > > sysUDelayFlash (0x64);
> > > hard_reg = (void*)0xb8519860;
> > > *hard_reg = *hard_reg |0x2;
> > > channelSelect = 0x2;
> > > for (ii=0; (ii< 0x3FFFE) && channelSelect ;ii++)channelSelect =
> > > *hard_reg & 0x2;
> > >
> > > hard_reg = (void*)0xB8510024; *hard_reg = 0x1;
> > >
> > > }
> > >
> >
> > Hi Ivan
> >
> > Do you intend to suggest that I can call this function directly for
> > switching the frequency?? If so could you please explain as to what the
> > function does. You are setting the values for the variable, hard_reg and
> > channelSelect, but dont you need to set these values in the register so
> that
> > the hardware actually changes the channel?
> >
> > Also what is the definition for the function, sysUDelayFlash () since it
> is
> > not available in the madwifi code.
> >
> > Thanks
> > Vishal
> >
> > >
> > > -----Original Message-----
> > > From: Vishal Sevani <vis...@gm...>
> > > To: mad...@li...
> > > Date: Mon, 22 Feb 2010 14:10:04 +0530
> > > Subject: Re: [Madwifi-users] Fast channel switching
> > >
> > > > On Sat, Feb 20, 2010 at 5:00 AM, Pavel Roskin <pr...@gn...>
> wrote:
> > > >
> > > > > On Fri, 2010-02-19 at 15:17 +0530, Vishal Sevani wrote:
> > > > >
> > > > > > > I did apply the following patch
> > > > > > > https://madwifi-project.org/ticket/2322 , but to no
> avail.
> > > > > > Could you
> > > > > > > point out as to what the problem could be?? If you need
> me
> > > > > > to provide
> > > > > > > any other debug information please do let me know.
> > > > > >
> > > > > >
> > > > > > I'll appreciate if you post your results to the ticket.
> So
> > > > > > far there
> > > > > > have been no test results for that patch at all.
> > > > > >
> > > > > > Yeah I have posted my experience in the following ticket.
> > > > > > https://madwifi-project.org/ticket/2359
> > > > >
> > > > > I actually I meant that you would report a negative result with the
> > > > > patch in #2322. But it looks like the problems are different.
> > > > >
> > > > > Yeah it seems more of a hardware issue with AR71xx borad, (or issue
> > > with
> > > > Openwrt) as pointed out by ne...@pa... in his comment
> following
> > > yours
> > > > in the ticket #2359. If Iam correct, it is happening because the
> value in
> > > > reg AR_ISR corresponding to flag AR_ISR_HIUERR is being set, which is
> for
> > > > unexpected bus error. As mentioned in the following post
> > > > http://n2.nabble.com/fatal-interrupt-td3225930.html, it is beacuse
> the
> > > > following bit, AR_ISR_S2_MCABT (for master cycle abort) is being
> set.
> > > >
> > > > Iam clueless as to what could be causing this master cycle abort
> problem
> > > and
> > > > how should I go about debugging it. Could you please provide any
> pointers
> > > as
> > > > to how I can rectify this problem.
> > > >
> > > >
> > > > > > Yesterday again I tried with latest release of Openwrt Kamikaze
> ie.
> > > > > > v8.09.2, but still I get the same problem. But the madwifi code
> works
> > > > > > properly on IBM latop running Ubuntu with Linux kernel 2.6.24-23.
> So
> > > I
> > > > > > guess it is the issue with Openwrt or the hardware ie. AR71xx
> boards.
> > > > > > Has the latest code been tested on Openwrt and Ar71xx boards??
> > > > >
> > > > > I'm not aware of it.
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Pavel Roskin
> > > > >
> > > >
> > > >
> > >
> ------------------------------------------------------------------------------
> > > > Download Intel Parallel Studio Eval
> > > > Try the new software tools for yourself. Speed compiling, find bugs
> > > > proactively, and fine-tune applications for parallel performance.
> > > > See why Intel Parallel Studio got high marks during beta.
> > > > http://p.sf.net/sfu/intel-sw-dev
> > > > _______________________________________________
> > > > Madwifi-users mailing list
> > > > Mad...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> > > >
> > > >
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Download Intel Parallel Studio Eval
> > > Try the new software tools for yourself. Speed compiling, find bugs
> > > proactively, and fine-tune applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > Madwifi-users mailing list
> > > Mad...@li...
> > > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> > >
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Madwifi-users mailing list
> > Mad...@li...
> > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> >
> >
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Madwifi-users mailing list
> Mad...@li...
> https://lists.sourceforge.net/lists/listinfo/madwifi-users
>
|
|
From: IVAN K. <200...@ma...> - 2010-02-24 10:15:28
|
100 microsecond too small ...
need 30 ... 50 ms
> Hi Ivan
>
> Thanks a lot for the help. The function seems to be working, although I had
> to make few changes. If I used the addess, 0xb8510024 for AR_IER it was
> giving segmentation fault. However it did work with address 0x0024 (likewise
> for other registers too). But although the frequency does get changed, it
> does not get reflected in iwconfig command. For it I guess I will have to
> set the member variable ic_curchan of variable ic (of type ieee80211com),
> which Iam trying to figure out.
>
> However one of the other issues is that this function is taking about 30ms
> for switching the channel (I have tested it on x86 based IBM laptop).
> Whereas we need a channel switching functionality of the order of
> microseconds (preferably around 500 microseconds if possible). On analyzing
> your function I observed that following for loop
>
> for (ii=0; (ii< 0x3FFFE) && channelSelect ;ii++)channelSelect =*hard_reg &
> 0x2;
>
> takes about 30ms. Although in place of this for loop I put a delay of about
> 100 microsecond and it does seem to work (though I have to test thouroughly
> as to whether any packets are getting lost). Also Iam trying to figure the
> optimal values for the different delays that you have called in your
> function.
>
> Could you please let me know as to on what basis have you come up with these
> different values of delay (ie. 0x3E8, 0xA, 0x64, and the for loop), as it
> would help me in optimizing these values for my hardware.
>
> Thanks
> Vishal
>
> On Tue, Feb 23, 2010 at 1:27 PM, IVAN KORSHUN <200...@ma...> wrote:
>
> > sysUDelayFlash its ath_hal_delay(int n) /* Delay n microseconds */
> > I use non Linux OS ...
> >
> > ar5212SetChannel5112work2192(2192); //set freq 2192 MHz
> > ar5212SetChannel5112work2192(2195); //set freq 2195 MHz
> > ...
> > ar5212SetChannel5112work2192(2512); //set freq 2512 MHz
> >
> > and hard_reg ...
> > 0xB8510024 its AR_IER 0x0024 /* MAC Interrupt enable
> > register */
> > 0xb851981c its AR_PHY_ACTIVE 0x981C /* activation register */
> > 0xb8519860 its AR_PHY_AGC_CONTROL 0x9860 /* chip calibration and
> > noise floor setting */
> >
> > 0xb851989C & 0xb85198D8 its regs for internal use ...
> >
> >
> > -----Original Message-----
> > From: Vishal Sevani <vis...@gm...>
> > To: mad...@li...
> > Date: Tue, 23 Feb 2010 12:05:05 +0530
> > Subject: Re: [Madwifi-users] Fast channel switching
> >
> > > On Mon, Feb 22, 2010 at 10:19 PM, IVAN KORSHUN <200...@ma...>
> > wrote:
> > >
> > > > void ar5212SetChannel5112work2192(UINT32 freq)
> > > > {
> > > > /* Step 5 MHz */
> > > > UINT32 ii,channelSelect;
> > > > volatile UINT32 *hard_reg;
> > > >
> > > > channelSelect = ((freq - 672) * 2 - 3040)/10;
> > > > channelSelect = (channelSelect << 2) & 0xff;
> > > > channelSelect = ath_hal_reverseBits(channelSelect, 8);
> > > >
> > > >
> > > > channelSelect = (channelSelect << 4) | 0x1005;
> > > >
> > > > hard_reg = (void*)0xB8510024; *hard_reg = 0x0;
> > > > sysUDelayFlash (0x3E8);
> > > > hard_reg = (void*)0xb851981c; *hard_reg = 0x0;
> > > > sysUDelayFlash (0xA);
> > > > hard_reg = (void*)0xb851989C; *hard_reg = (channelSelect &
> > 0xff);
> > > >
> > > > channelSelect = (channelSelect >> 8) & 0x7f;
> > > > hard_reg = (void*)0xb85198D8; *hard_reg = channelSelect;
> > > > sysUDelayFlash (0xA);
> > > > hard_reg = (void*)0xb851981c; *hard_reg = 0x1;
> > > > sysUDelayFlash (0x64);
> > > > hard_reg = (void*)0xb8519860;
> > > > *hard_reg = *hard_reg |0x2;
> > > > channelSelect = 0x2;
> > > > for (ii=0; (ii< 0x3FFFE) && channelSelect ;ii++)channelSelect =
> > > > *hard_reg & 0x2;
> > > >
> > > > hard_reg = (void*)0xB8510024; *hard_reg = 0x1;
> > > >
> > > > }
> > > >
> > >
> > > Hi Ivan
> > >
> > > Do you intend to suggest that I can call this function directly for
> > > switching the frequency?? If so could you please explain as to what the
> > > function does. You are setting the values for the variable, hard_reg and
> > > channelSelect, but dont you need to set these values in the register so
> > that
> > > the hardware actually changes the channel?
> > >
> > > Also what is the definition for the function, sysUDelayFlash () since it
> > is
> > > not available in the madwifi code.
> > >
> > > Thanks
> > > Vishal
> > >
> > > >
> > > > -----Original Message-----
> > > > From: Vishal Sevani <vis...@gm...>
> > > > To: mad...@li...
> > > > Date: Mon, 22 Feb 2010 14:10:04 +0530
> > > > Subject: Re: [Madwifi-users] Fast channel switching
> > > >
> > > > > On Sat, Feb 20, 2010 at 5:00 AM, Pavel Roskin <pr...@gn...>
> > wrote:
> > > > >
> > > > > > On Fri, 2010-02-19 at 15:17 +0530, Vishal Sevani wrote:
> > > > > >
> > > > > > > > I did apply the following patch
> > > > > > > > https://madwifi-project.org/ticket/2322 , but to no
> > avail.
> > > > > > > Could you
> > > > > > > > point out as to what the problem could be?? If you need
> > me
> > > > > > > to provide
> > > > > > > > any other debug information please do let me know.
> > > > > > >
> > > > > > >
> > > > > > > I'll appreciate if you post your results to the ticket.
> > So
> > > > > > > far there
> > > > > > > have been no test results for that patch at all.
> > > > > > >
> > > > > > > Yeah I have posted my experience in the following ticket.
> > > > > > > https://madwifi-project.org/ticket/2359
> > > > > >
> > > > > > I actually I meant that you would report a negative result with the
> > > > > > patch in #2322. But it looks like the problems are different.
> > > > > >
> > > > > > Yeah it seems more of a hardware issue with AR71xx borad, (or issue
> > > > with
> > > > > Openwrt) as pointed out by ne...@pa... in his comment
> > following
> > > > yours
> > > > > in the ticket #2359. If Iam correct, it is happening because the
> > value in
> > > > > reg AR_ISR corresponding to flag AR_ISR_HIUERR is being set, which is
> > for
> > > > > unexpected bus error. As mentioned in the following post
> > > > > http://n2.nabble.com/fatal-interrupt-td3225930.html, it is beacuse
> > the
> > > > > following bit, AR_ISR_S2_MCABT (for master cycle abort) is being
> > set.
> > > > >
> > > > > Iam clueless as to what could be causing this master cycle abort
> > problem
> > > > and
> > > > > how should I go about debugging it. Could you please provide any
> > pointers
> > > > as
> > > > > to how I can rectify this problem.
> > > > >
> > > > >
> > > > > > > Yesterday again I tried with latest release of Openwrt Kamikaze
> > ie.
> > > > > > > v8.09.2, but still I get the same problem. But the madwifi code
> > works
> > > > > > > properly on IBM latop running Ubuntu with Linux kernel 2.6.24-23.
> > So
> > > > I
> > > > > > > guess it is the issue with Openwrt or the hardware ie. AR71xx
> > boards.
> > > > > > > Has the latest code been tested on Openwrt and Ar71xx boards??
> > > > > >
> > > > > > I'm not aware of it.
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > Pavel Roskin
> > > > > >
> > > > >
> > > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > > Download Intel Parallel Studio Eval
> > > > > Try the new software tools for yourself. Speed compiling, find bugs
> > > > > proactively, and fine-tune applications for parallel performance.
> > > > > See why Intel Parallel Studio got high marks during beta.
> > > > > http://p.sf.net/sfu/intel-sw-dev
> > > > > _______________________________________________
> > > > > Madwifi-users mailing list
> > > > > Mad...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > Download Intel Parallel Studio Eval
> > > > Try the new software tools for yourself. Speed compiling, find bugs
> > > > proactively, and fine-tune applications for parallel performance.
> > > > See why Intel Parallel Studio got high marks during beta.
> > > > http://p.sf.net/sfu/intel-sw-dev
> > > > _______________________________________________
> > > > Madwifi-users mailing list
> > > > Mad...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> > > >
> > >
> > >
> > ------------------------------------------------------------------------------
> > > Download Intel Parallel Studio Eval
> > > Try the new software tools for yourself. Speed compiling, find bugs
> > > proactively, and fine-tune applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > Madwifi-users mailing list
> > > Mad...@li...
> > > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> > >
> > >
> >
> >
> > ------------------------------------------------------------------------------
> > Download Intel Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Madwifi-users mailing list
> > Mad...@li...
> > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> >
>
> ------------------------------------------------------------------------------
> Download Intel Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Madwifi-users mailing list
> Mad...@li...
> https://lists.sourceforge.net/lists/listinfo/madwifi-users
>
>
|
|
From: Vishal S. <vis...@gm...> - 2010-02-25 11:34:09
|
800 -- 1000 microseconds seems to be working (in ahdemo mode atleast),
though I have to test intensely. But why do u suggest 30 - 50ms, is it
harware limitation or it is an issue with madwifi driver??
On Wed, Feb 24, 2010 at 3:45 PM, IVAN KORSHUN <200...@ma...> wrote:
> 100 microsecond too small ...
> need 30 ... 50 ms
>
>
> > Hi Ivan
> >
> > Thanks a lot for the help. The function seems to be working, although I
> had
> > to make few changes. If I used the addess, 0xb8510024 for AR_IER it was
> > giving segmentation fault. However it did work with address 0x0024
> (likewise
> > for other registers too). But although the frequency does get changed, it
> > does not get reflected in iwconfig command. For it I guess I will have to
> > set the member variable ic_curchan of variable ic (of type ieee80211com),
> > which Iam trying to figure out.
> >
> > However one of the other issues is that this function is taking about
> 30ms
> > for switching the channel (I have tested it on x86 based IBM laptop).
> > Whereas we need a channel switching functionality of the order of
> > microseconds (preferably around 500 microseconds if possible). On
> analyzing
> > your function I observed that following for loop
> >
> > for (ii=0; (ii< 0x3FFFE) && channelSelect ;ii++)channelSelect =*hard_reg
> &
> > 0x2;
> >
> > takes about 30ms. Although in place of this for loop I put a delay of
> about
> > 100 microsecond and it does seem to work (though I have to test
> thouroughly
> > as to whether any packets are getting lost). Also Iam trying to figure
> the
> > optimal values for the different delays that you have called in your
> > function.
> >
> > Could you please let me know as to on what basis have you come up with
> these
> > different values of delay (ie. 0x3E8, 0xA, 0x64, and the for loop), as it
> > would help me in optimizing these values for my hardware.
> >
> > Thanks
> > Vishal
> >
> > On Tue, Feb 23, 2010 at 1:27 PM, IVAN KORSHUN <200...@ma...> wrote:
> >
> > > sysUDelayFlash its ath_hal_delay(int n) /* Delay n microseconds */
> > > I use non Linux OS ...
> > >
> > > ar5212SetChannel5112work2192(2192); //set freq 2192 MHz
> > > ar5212SetChannel5112work2192(2195); //set freq 2195 MHz
> > > ...
> > > ar5212SetChannel5112work2192(2512); //set freq 2512 MHz
> > >
> > > and hard_reg ...
> > > 0xB8510024 its AR_IER 0x0024 /* MAC Interrupt enable
> > > register */
> > > 0xb851981c its AR_PHY_ACTIVE 0x981C /* activation register
> */
> > > 0xb8519860 its AR_PHY_AGC_CONTROL 0x9860 /* chip calibration and
> > > noise floor setting */
> > >
> > > 0xb851989C & 0xb85198D8 its regs for internal use ...
> > >
> > >
> > > -----Original Message-----
> > > From: Vishal Sevani <vis...@gm...>
> > > To: mad...@li...
> > > Date: Tue, 23 Feb 2010 12:05:05 +0530
> > > Subject: Re: [Madwifi-users] Fast channel switching
> > >
> > > > On Mon, Feb 22, 2010 at 10:19 PM, IVAN KORSHUN <200...@ma...>
> > > wrote:
> > > >
> > > > > void ar5212SetChannel5112work2192(UINT32 freq)
> > > > > {
> > > > > /* Step 5 MHz */
> > > > > UINT32 ii,channelSelect;
> > > > > volatile UINT32 *hard_reg;
> > > > >
> > > > > channelSelect = ((freq - 672) * 2 - 3040)/10;
> > > > > channelSelect = (channelSelect << 2) & 0xff;
> > > > > channelSelect = ath_hal_reverseBits(channelSelect, 8);
> > > > >
> > > > >
> > > > > channelSelect = (channelSelect << 4) | 0x1005;
> > > > >
> > > > > hard_reg = (void*)0xB8510024; *hard_reg = 0x0;
> > > > > sysUDelayFlash (0x3E8);
> > > > > hard_reg = (void*)0xb851981c; *hard_reg = 0x0;
> > > > > sysUDelayFlash (0xA);
> > > > > hard_reg = (void*)0xb851989C; *hard_reg = (channelSelect &
> > > 0xff);
> > > > >
> > > > > channelSelect = (channelSelect >> 8) & 0x7f;
> > > > > hard_reg = (void*)0xb85198D8; *hard_reg = channelSelect;
> > > > > sysUDelayFlash (0xA);
> > > > > hard_reg = (void*)0xb851981c; *hard_reg = 0x1;
> > > > > sysUDelayFlash (0x64);
> > > > > hard_reg = (void*)0xb8519860;
> > > > > *hard_reg = *hard_reg |0x2;
> > > > > channelSelect = 0x2;
> > > > > for (ii=0; (ii< 0x3FFFE) && channelSelect
> ;ii++)channelSelect =
> > > > > *hard_reg & 0x2;
> > > > >
> > > > > hard_reg = (void*)0xB8510024; *hard_reg = 0x1;
> > > > >
> > > > > }
> > > > >
> > > >
> > > > Hi Ivan
> > > >
> > > > Do you intend to suggest that I can call this function directly for
> > > > switching the frequency?? If so could you please explain as to what
> the
> > > > function does. You are setting the values for the variable, hard_reg
> and
> > > > channelSelect, but dont you need to set these values in the register
> so
> > > that
> > > > the hardware actually changes the channel?
> > > >
> > > > Also what is the definition for the function, sysUDelayFlash ()
> since it
> > > is
> > > > not available in the madwifi code.
> > > >
> > > > Thanks
> > > > Vishal
> > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Vishal Sevani <vis...@gm...>
> > > > > To: mad...@li...
> > > > > Date: Mon, 22 Feb 2010 14:10:04 +0530
> > > > > Subject: Re: [Madwifi-users] Fast channel switching
> > > > >
> > > > > > On Sat, Feb 20, 2010 at 5:00 AM, Pavel Roskin <pr...@gn...>
> > > wrote:
> > > > > >
> > > > > > > On Fri, 2010-02-19 at 15:17 +0530, Vishal Sevani wrote:
> > > > > > >
> > > > > > > > > I did apply the following patch
> > > > > > > > > https://madwifi-project.org/ticket/2322 , but to
> no
> > > avail.
> > > > > > > > Could you
> > > > > > > > > point out as to what the problem could be?? If you
> need
> > > me
> > > > > > > > to provide
> > > > > > > > > any other debug information please do let me know.
> > > > > > > >
> > > > > > > >
> > > > > > > > I'll appreciate if you post your results to the
> ticket.
> > > So
> > > > > > > > far there
> > > > > > > > have been no test results for that patch at all.
> > > > > > > >
> > > > > > > > Yeah I have posted my experience in the following ticket.
> > > > > > > > https://madwifi-project.org/ticket/2359
> > > > > > >
> > > > > > > I actually I meant that you would report a negative result with
> the
> > > > > > > patch in #2322. But it looks like the problems are different.
> > > > > > >
> > > > > > > Yeah it seems more of a hardware issue with AR71xx borad, (or
> issue
> > > > > with
> > > > > > Openwrt) as pointed out by ne...@pa... in his comment
> > > following
> > > > > yours
> > > > > > in the ticket #2359. If Iam correct, it is happening because the
> > > value in
> > > > > > reg AR_ISR corresponding to flag AR_ISR_HIUERR is being set,
> which is
> > > for
> > > > > > unexpected bus error. As mentioned in the following post
> > > > > > http://n2.nabble.com/fatal-interrupt-td3225930.html, it is
> beacuse
> > > the
> > > > > > following bit, AR_ISR_S2_MCABT (for master cycle abort) is being
> > > set.
> > > > > >
> > > > > > Iam clueless as to what could be causing this master cycle abort
> > > problem
> > > > > and
> > > > > > how should I go about debugging it. Could you please provide any
> > > pointers
> > > > > as
> > > > > > to how I can rectify this problem.
> > > > > >
> > > > > >
> > > > > > > > Yesterday again I tried with latest release of Openwrt
> Kamikaze
> > > ie.
> > > > > > > > v8.09.2, but still I get the same problem. But the madwifi
> code
> > > works
> > > > > > > > properly on IBM latop running Ubuntu with Linux kernel
> 2.6.24-23.
> > > So
> > > > > I
> > > > > > > > guess it is the issue with Openwrt or the hardware ie. AR71xx
> > > boards.
> > > > > > > > Has the latest code been tested on Openwrt and Ar71xx
> boards??
> > > > > > >
> > > > > > > I'm not aware of it.
> > > > > > >
> > > > > > > --
> > > > > > > Regards,
> > > > > > > Pavel Roskin
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > >
> ------------------------------------------------------------------------------
> > > > > > Download Intel Parallel Studio Eval
> > > > > > Try the new software tools for yourself. Speed compiling, find
> bugs
> > > > > > proactively, and fine-tune applications for parallel performance.
> > > > > > See why Intel Parallel Studio got high marks during beta.
> > > > > > http://p.sf.net/sfu/intel-sw-dev
> > > > > > _______________________________________________
> > > > > > Madwifi-users mailing list
> > > > > > Mad...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > >
> ------------------------------------------------------------------------------
> > > > > Download Intel Parallel Studio Eval
> > > > > Try the new software tools for yourself. Speed compiling, find bugs
> > > > > proactively, and fine-tune applications for parallel performance.
> > > > > See why Intel Parallel Studio got high marks during beta.
> > > > > http://p.sf.net/sfu/intel-sw-dev
> > > > > _______________________________________________
> > > > > Madwifi-users mailing list
> > > > > Mad...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> > > > >
> > > >
> > > >
> > >
> ------------------------------------------------------------------------------
> > > > Download Intel Parallel Studio Eval
> > > > Try the new software tools for yourself. Speed compiling, find bugs
> > > > proactively, and fine-tune applications for parallel performance.
> > > > See why Intel Parallel Studio got high marks during beta.
> > > > http://p.sf.net/sfu/intel-sw-dev
> > > > _______________________________________________
> > > > Madwifi-users mailing list
> > > > Mad...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> > > >
> > > >
> > >
> > >
> > >
> ------------------------------------------------------------------------------
> > > Download Intel Parallel Studio Eval
> > > Try the new software tools for yourself. Speed compiling, find bugs
> > > proactively, and fine-tune applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > Madwifi-users mailing list
> > > Mad...@li...
> > > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> > >
> >
> >
> ------------------------------------------------------------------------------
> > Download Intel Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Madwifi-users mailing list
> > Mad...@li...
> > https://lists.sourceforge.net/lists/listinfo/madwifi-users
> >
> >
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Madwifi-users mailing list
> Mad...@li...
> https://lists.sourceforge.net/lists/listinfo/madwifi-users
>
|
Thanks for helping keep SourceForge clean.
X