Hi folks -
Just seemed a little strange, maybe it is perfectly fine.
iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
PM: Adding info for No Bus:phy0
PM: Adding info for No Bus:wmaster0
wmaster0: Selected rate control algorithm 'iwl-3945-rs'
...but then we add an rt73usb...
PM: Adding info for No Bus:phy1
PM: Adding info for No Bus:wmaster1
wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
PM: Adding info for No Bus:wlan1
usbcore: registered new interface driver rt73usb
-Andy
On Wed, 2007-08-01 at 14:23 +0200, Jiri Benc wrote:
> Yes. But I'd like to see a solution to the problem reported by Andy in
> the patch. One of the possible solutions could be adding a "this is a
> special rate control alg which shouldn't be selected automatically"
> flag to rate control algs and not selecting such algorithms in
> ieee80211_try_rate_control_ops_get when 'name' is NULL. Should be easy
> to implement.
Maybe go all the way then and somehow tie it to specific information it
requires from the hardware that most hardware doesn't give it?
johannes
On Wed, 01 Aug 2007 11:32:44 +0200, Johannes Berg wrote:
> On Tue, 2007-07-31 at 20:45 -0400, John W. Linville wrote:
>
> > > Just seemed a little strange, maybe it is perfectly fine.
> > >
> > > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > > PM: Adding info for No Bus:phy0
> > > PM: Adding info for No Bus:wmaster0
> > > wmaster0: Selected rate control algorithm 'iwl-3945-rs'
> > >
> > > ...but then we add an rt73usb...
> > >
> > > PM: Adding info for No Bus:phy1
> > > PM: Adding info for No Bus:wmaster1
> > > wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
> > > PM: Adding info for No Bus:wlan1
> > > usbcore: registered new interface driver rt73usb
>
> Weird. But I guess that's because iwl-3945-rs is loaded and available so
> it's chosen first or something.
Exactly. This is one of things that should be solved in the patch
mentioned below.
> > This looks like the reverse of a dust-up we had a couple of months ago:
> >
> > http://marc.info/?l=linux-wireless&m=117875332512693&w=2
> >
> > It is possible to change the rate control algorithm now via debugfs.
> > In the past someone proposed letting drivers request their default
> > rate scaling algorithm, and I think that makes a lot of sense.
> > Any thoughts?
Still waiting for a patch from Intel.
> Apply the patch already? IIRC James made a pretty good one around that
> time to let the driver choose a default name as part of the hw structure
> it registers and it can be NULL for the default.
>
> Of course, in a perfect world we'd have a 'default' rate control setting
> somewhere and apply that for drivers that have rate_control==NULL, while
> default would default to 'simple' to avoid the issue above.
I'd really like to see that in the patch. Seems to be a real issue.
Jiri
--
Jiri Benc
SUSE Labs
On Wed, 01 Aug 2007 13:54:15 +0200, Johannes Berg wrote:
> I suppose you mean this patch
> http://article.gmane.org/gmane.linux.kernel.wireless.general/2303
Yes. But I'd like to see a solution to the problem reported by Andy in
the patch. One of the possible solutions could be adding a "this is a
special rate control alg which shouldn't be selected automatically"
flag to rate control algs and not selecting such algorithms in
ieee80211_try_rate_control_ops_get when 'name' is NULL. Should be easy
to implement.
> > > Of course, in a perfect world we'd have a 'default' rate control setting
> > > somewhere and apply that for drivers that have rate_control==NULL, while
> > > default would default to 'simple' to avoid the issue above.
That's a possible solution too, though not an ideal one. Currently, you
can use module alias to change default rate control algorithm - at
least for simple setups. This would break it.
> > I'd really like to see that in the patch. Seems to be a real issue.
>
> Except that we have no API for that (should be in cfg80211.)
We will need an API for changing of rate control alg from the user
space, sure - but that's not an issue here, this patch is purely
mac80211 thing.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
On Tue, 2007-07-31 at 20:45 -0400, John W. Linville wrote:
> > Just seemed a little strange, maybe it is perfectly fine.
> >
> > iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> > PM: Adding info for No Bus:phy0
> > PM: Adding info for No Bus:wmaster0
> > wmaster0: Selected rate control algorithm 'iwl-3945-rs'
> >
> > ...but then we add an rt73usb...
> >
> > PM: Adding info for No Bus:phy1
> > PM: Adding info for No Bus:wmaster1
> > wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
> > PM: Adding info for No Bus:wlan1
> > usbcore: registered new interface driver rt73usb
Weird. But I guess that's because iwl-3945-rs is loaded and available so
it's chosen first or something.
> This looks like the reverse of a dust-up we had a couple of months ago:
>
> http://marc.info/?l=linux-wireless&m=117875332512693&w=2
>
> It is possible to change the rate control algorithm now via debugfs.
> In the past someone proposed letting drivers request their default
> rate scaling algorithm, and I think that makes a lot of sense.
> Any thoughts?
Apply the patch already? IIRC James made a pretty good one around that
time to let the driver choose a default name as part of the hw structure
it registers and it can be NULL for the default.
Of course, in a perfect world we'd have a 'default' rate control setting
somewhere and apply that for drivers that have rate_control==NULL, while
default would default to 'simple' to avoid the issue above.
johannes
On Wed, 2007-08-01 at 13:46 +0200, Jiri Benc wrote:
> Exactly. This is one of things that should be solved in the patch
> mentioned below.
I suppose you mean this patch
http://article.gmane.org/gmane.linux.kernel.wireless.general/2303
> > Apply the patch already? IIRC James made a pretty good one around that
> > time to let the driver choose a default name as part of the hw structure
> > it registers and it can be NULL for the default.
> >
> > Of course, in a perfect world we'd have a 'default' rate control setting
> > somewhere and apply that for drivers that have rate_control==NULL, while
> > default would default to 'simple' to avoid the issue above.
>
> I'd really like to see that in the patch. Seems to be a real issue.
Except that we have no API for that (should be in cfg80211.)
johannes
On Tue, Jul 31, 2007 at 11:28:09PM +0100, Andy Green wrote:
> Hi folks -
>
> Just seemed a little strange, maybe it is perfectly fine.
>
> iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels
> PM: Adding info for No Bus:phy0
> PM: Adding info for No Bus:wmaster0
> wmaster0: Selected rate control algorithm 'iwl-3945-rs'
>
> ...but then we add an rt73usb...
>
> PM: Adding info for No Bus:phy1
> PM: Adding info for No Bus:wmaster1
> wmaster1: Selected rate control algorithm 'iwl-3945-rs' <----
> PM: Adding info for No Bus:wlan1
> usbcore: registered new interface driver rt73usb
This looks like the reverse of a dust-up we had a couple of months ago:
http://marc.info/?l=linux-wireless&m=117875332512693&w=2
It is possible to change the rate control algorithm now via debugfs.
In the past someone proposed letting drivers request their default
rate scaling algorithm, and I think that makes a lot of sense.
Any thoughts?
John
--
John W. Linville
[email protected]