* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: John W. Linville @ 2010-05-04 17:17 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: Pavel Roskin, Stefan Lippers-Hollmann, Ivo van Doorn,
linux-wireless, users
In-Reply-To: <4BDF94FD.7050606@gmail.com>
On Tue, May 04, 2010 at 05:31:09AM +0200, Gertjan van Wingerde wrote:
> To be honest, at the moment I would just change the default from 'n' to 'y'
> for one kernel cycle, and then remove the entire option in the next kernel
> release.
> This is just to make it easier to revert back if for some reasons problems
> arise with the rt30xx support.
> The overall goal is to get rid of all these of the RT2800PCI_yyy and RT2800USB_zzz
> symbols, but that can only happen if the devices denoted by these symbols
> are properly supported.
>
> John, I leave it up to you, but for me my original patch should be merged, and
> I'll send an equivalent patch for Stefan's one for the next kernel release.
Since the options are already inside "if RT2800PCI" and "if RT2800USB"
blocks, I don't see why anyone should object to the boolean defaulting
to 'y'. It's not as if you are enabling a new driver.
I think Gertjan's proposal seems reasonable -- just don't forget! :-)
I would suggest a feature-removal-schedlue.txt patch, but I don't
know that it is worth the trouble.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [Fwd: USB AP card and/or rt2870 issue]
From: GNUtoo @ 2010-05-04 17:33 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: linux-wireless
In-Reply-To: <q2na32f33a41005040832n7d50a934q4ff0a6a4dde53f28@mail.gmail.com>
On Tue, 2010-05-04 at 17:32 +0200, Ivo Van Doorn wrote:
> On Tue, May 4, 2010 at 5:28 PM, GNUtoo <GNUtoo@no-log.org> wrote:
> > hi, I sent the following mail(attached) to the hostapd mailing list,but
> > Now I think It's a driver issue.
> > Is it possible to make an access point with a rt2870 card.
> > Does the driver support it?
> > I don't have much hope for now as it is a staging driver...and it
> > displayed a warning about that in dmesg...
>
> You could try compat-wireless and the rt2800usb driver.
> That one actually does have Master mode support, but doesn't work
> on all cards yet. rt2800usb is also found in the main kernel tree, but
> using compat-wireless will give you the most recent version with
> _many_ fixes applied to it. :)
I tried that,
hostapd put the card in master mode
unfortunately once in master mode,impossible to find the essid when
scanning.
Denis.
^ permalink raw reply
* Philosophical question about channel selection
From: Larry Finger @ 2010-05-04 17:54 UTC (permalink / raw)
To: wireless
A question has been posed on the openSUSE wireless forum that I do not
know how to answer.
In a given neighborhood, there are 802.11g APs at roughly the same
strength on channels 1 and 10 (yes - 10). As this configuration ensures
that there are no clear channels, what would be the best choice? As I
see it, the options are ch 1 with interference across the full channel
width, ch 6 with interference only at the upper end, or ch 11. Which
would get the best throughput?
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH] ath9k: fix another source of corrupt frames
From: Luis R. Rodriguez @ 2010-05-04 18:09 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, John W. Linville
In-Reply-To: <4BDFD3C1.4000209@openwrt.org>
On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> Atheros hardware supports receiving frames that span multiple
> descriptors and buffers. In this case, the rx status of every
> descriptor except for the last one is invalid and may contain random
> data. Because the driver does not support this, it needs to drop such
> frames.
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> ---
> --- a/drivers/net/wireless/ath/ath9k/common.c
> +++ b/drivers/net/wireless/ath/ath9k/common.c
> @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
> * rs_more indicates chained descriptors which can be used
> * to link buffers together for a sort of scatter-gather
> * operation.
> - *
> + * reject the frame, we don't support scatter-gather yet and
> + * the frame is probably corrupt anyway
> + */
> + if (rx_stats->rs_more)
> + return false;
Actually this is required by ath9k_htc, it does process these, but
ath9k doesn't so this could be done within ath9k itself.
Luis
^ permalink raw reply
* Re: Philosophical question about channel selection
From: Luis R. Rodriguez @ 2010-05-04 18:11 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless
In-Reply-To: <4BE05F6B.3060705@lwfinger.net>
On Tue, May 4, 2010 at 10:54 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> A question has been posed on the openSUSE wireless forum that I do not
> know how to answer.
>
> In a given neighborhood, there are 802.11g APs at roughly the same
> strength on channels 1 and 10 (yes - 10). As this configuration ensures
> that there are no clear channels, what would be the best choice? As I
> see it, the options are ch 1 with interference across the full channel
> width, ch 6 with interference only at the upper end, or ch 11. Which
> would get the best throughput?
Depends on how busy those APs are :) I'd use a minstrel type algorithm
to test :P
Luis
^ permalink raw reply
* Re: [PATCH] cfg80211: Check for channel HT capabilities in an IBSS
From: Luis R. Rodriguez @ 2010-05-04 18:14 UTC (permalink / raw)
To: Benoit Papillault; +Cc: johannes, linux-wireless
In-Reply-To: <1272955622-6987-2-git-send-email-benoit.papillault@free.fr>
On Mon, May 3, 2010 at 11:47 PM, Benoit Papillault
<benoit.papillault@free.fr> wrote:
> When configuring an HT IBSS, we need to check if the specified channel
> is capable of ht40+, ht40- or ht20.
>
> Signed-off-by: Benoit Papillault <benoit.papillault@free.fr>
> ---
> net/wireless/nl80211.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 8da9823..0a82623 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -3858,11 +3858,11 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
> ibss.ie_len = nla_len(info->attrs[NL80211_ATTR_IE]);
> }
>
> - ibss.channel = ieee80211_get_channel(wiphy,
> - nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]));
> + ibss.channel = rdev_freq_to_chan(rdev,
> + nla_get_u32(info->attrs[NL80211_ATTR_WIPHY_FREQ]),
> + channel_type);
> if (!ibss.channel ||
> - ibss.channel->flags & IEEE80211_CHAN_NO_IBSS ||
> - ibss.channel->flags & IEEE80211_CHAN_DISABLED) {
> + ibss.channel->flags & IEEE80211_CHAN_NO_IBSS) {
> err = -EINVAL;
Why is the disabled channel check being removed here?
Luis
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Gertjan van Wingerde @ 2010-05-04 18:22 UTC (permalink / raw)
To: John W. Linville
Cc: Pavel Roskin, Stefan Lippers-Hollmann, Ivo van Doorn,
linux-wireless, users
In-Reply-To: <20100504171720.GA21043@tuxdriver.com>
On 05/04/10 19:17, John W. Linville wrote:
> On Tue, May 04, 2010 at 05:31:09AM +0200, Gertjan van Wingerde wrote:
>
>> To be honest, at the moment I would just change the default from 'n' to 'y'
>> for one kernel cycle, and then remove the entire option in the next kernel
>> release.
>> This is just to make it easier to revert back if for some reasons problems
>> arise with the rt30xx support.
>> The overall goal is to get rid of all these of the RT2800PCI_yyy and RT2800USB_zzz
>> symbols, but that can only happen if the devices denoted by these symbols
>> are properly supported.
>>
>> John, I leave it up to you, but for me my original patch should be merged, and
>> I'll send an equivalent patch for Stefan's one for the next kernel release.
>
> Since the options are already inside "if RT2800PCI" and "if RT2800USB"
> blocks, I don't see why anyone should object to the boolean defaulting
> to 'y'. It's not as if you are enabling a new driver.
>
> I think Gertjan's proposal seems reasonable -- just don't forget! :-)
> I would suggest a feature-removal-schedlue.txt patch, but I don't
> know that it is worth the trouble.
>
Don't worry. I won't forget. I introduced these configuration items simply to
be able to disable non-functional devices from the driver. Once all devices are
working properly I will remove all of these Kconfig variables.
Feature-removal-schedule.txt seems like a lot of overkill, as we are not actually
removing features, we are simply unconditionally enabling code.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH] compat-wireless, unload rt2800usb
From: Luis R. Rodriguez @ 2010-05-04 18:23 UTC (permalink / raw)
To: Walter Goldens; +Cc: linux-wireless, users
In-Reply-To: <829828.92087.qm@web56808.mail.re3.yahoo.com>
On Tue, May 4, 2010 at 7:30 AM, Walter Goldens <goldenstranger@yahoo.com> wrote:
>
> Signed-off-by: Walter Goldens <goldenstranger@yahoo,com>
Applied, thanks!
Luis
^ permalink raw reply
* Re: HT rate warning with openwrt AP using wireless-compat and ath9k
From: Kalle Valo @ 2010-05-04 18:39 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <w2q43e72e891005031610uf6b912aduf271b0a97933d68a@mail.gmail.com>
"Luis R. Rodriguez" <mcgrof@gmail.com> writes:
>
> Can you enable ATH_DBG_XMIT on the box and see if this comes up?
>
> ATH_DBG_XMIT = 0x00000080,
>
> So just modprobe ath9k debug=0x80. I'll send an RFT patch soon.
I'm travelling right now and the AP is at home. I can test it
when I get back home, hopefully in two weeks.
/me prays for the volcano gods
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath9k: fix another source of corrupt frames
From: John W. Linville @ 2010-05-04 18:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Felix Fietkau, linux-wireless
In-Reply-To: <u2q43e72e891005041109i5106ba24ma7345c4f4c4fde21@mail.gmail.com>
On Tue, May 04, 2010 at 11:09:32AM -0700, Luis R. Rodriguez wrote:
> On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> > Atheros hardware supports receiving frames that span multiple
> > descriptors and buffers. In this case, the rx status of every
> > descriptor except for the last one is invalid and may contain random
> > data. Because the driver does not support this, it needs to drop such
> > frames.
> >
> > Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> > ---
> > --- a/drivers/net/wireless/ath/ath9k/common.c
> > +++ b/drivers/net/wireless/ath/ath9k/common.c
> > @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
> > * rs_more indicates chained descriptors which can be used
> > * to link buffers together for a sort of scatter-gather
> > * operation.
> > - *
> > + * reject the frame, we don't support scatter-gather yet and
> > + * the frame is probably corrupt anyway
> > + */
> > + if (rx_stats->rs_more)
> > + return false;
>
> Actually this is required by ath9k_htc, it does process these, but
> ath9k doesn't so this could be done within ath9k itself.
I'm sorry, that is a bit unclear to me. Are you NAKing the patch?
Or saying that the patch is fine but another patch is needed on top?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Walter Goldens @ 2010-05-04 19:09 UTC (permalink / raw)
To: John W. Linville, Gertjan van Wingerde
Cc: Ivo van Doorn, linux-wireless, users, Luis R. Rodriguez
In-Reply-To: <1272919385-18004-3-git-send-email-gwingerde@gmail.com>
> Now that RT30xx support is at the
> same level as RT28xx support we can enable
> these devices by default.
Shouldn't support for RT30xx be enabled by default for compat-wireless as well?
Walter.
^ permalink raw reply
* Re: [PATCH 2/4] rt2x00: Enable RT30xx by default.
From: Gertjan van Wingerde @ 2010-05-04 19:13 UTC (permalink / raw)
To: Walter Goldens
Cc: John W. Linville, Ivo van Doorn, linux-wireless, users,
Luis R. Rodriguez
In-Reply-To: <282593.4376.qm@web56802.mail.re3.yahoo.com>
On 05/04/10 21:09, Walter Goldens wrote:
>
>> Now that RT30xx support is at the
>> same level as RT28xx support we can enable
>> these devices by default.
>
> Shouldn't support for RT30xx be enabled by default for compat-wireless as well?
>
compat-wireless will be updated automatically once wireless-next-2.6 gets merged
into linux-next. Just have a bit of patience.
---
Gertjan.
^ permalink raw reply
* Re: [PATCH] ath9k: fix another source of corrupt frames
From: Felix Fietkau @ 2010-05-04 19:36 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, John W. Linville
In-Reply-To: <u2q43e72e891005041109i5106ba24ma7345c4f4c4fde21@mail.gmail.com>
On 2010-05-04 8:09 PM, Luis R. Rodriguez wrote:
> On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> Atheros hardware supports receiving frames that span multiple
>> descriptors and buffers. In this case, the rx status of every
>> descriptor except for the last one is invalid and may contain random
>> data. Because the driver does not support this, it needs to drop such
>> frames.
>>
>> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>> ---
>> --- a/drivers/net/wireless/ath/ath9k/common.c
>> +++ b/drivers/net/wireless/ath/ath9k/common.c
>> @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
>> * rs_more indicates chained descriptors which can be used
>> * to link buffers together for a sort of scatter-gather
>> * operation.
>> - *
>> + * reject the frame, we don't support scatter-gather yet and
>> + * the frame is probably corrupt anyway
>> + */
>> + if (rx_stats->rs_more)
>> + return false;
>
> Actually this is required by ath9k_htc, it does process these, but
> ath9k doesn't so this could be done within ath9k itself.
I don't see any place in ath9k_htc that processes rs_more. And even if
it did, processing the rx status of a frame that has more descriptors
chained after it would be wrong, since the rx status is only valid for
the last frame of the descriptor chain.
I think my patch would work fine for ath9k_htc as well.
- Felix
^ permalink raw reply
* Re: [PATCH] ath9k: fix another source of corrupt frames
From: Luis R. Rodriguez @ 2010-05-04 19:45 UTC (permalink / raw)
To: John W. Linville; +Cc: Luis Rodriguez, Felix Fietkau, linux-wireless
In-Reply-To: <20100504183613.GC21043@tuxdriver.com>
On Tue, May 04, 2010 at 11:36:13AM -0700, John W. Linville wrote:
> On Tue, May 04, 2010 at 11:09:32AM -0700, Luis R. Rodriguez wrote:
> > On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> > > Atheros hardware supports receiving frames that span multiple
> > > descriptors and buffers. In this case, the rx status of every
> > > descriptor except for the last one is invalid and may contain random
> > > data. Because the driver does not support this, it needs to drop such
> > > frames.
> > >
> > > Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> > > ---
> > > --- a/drivers/net/wireless/ath/ath9k/common.c
> > > +++ b/drivers/net/wireless/ath/ath9k/common.c
> > > @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
> > > * rs_more indicates chained descriptors which can be used
> > > * to link buffers together for a sort of scatter-gather
> > > * operation.
> > > - *
> > > + * reject the frame, we don't support scatter-gather yet and
> > > + * the frame is probably corrupt anyway
> > > + */
> > > + if (rx_stats->rs_more)
> > > + return false;
> >
> > Actually this is required by ath9k_htc, it does process these, but
> > ath9k doesn't so this could be done within ath9k itself.
>
> I'm sorry, that is a bit unclear to me. Are you NAKing the patch?
Yes, I am NAK'ing it, I should have been clearer about that, sorry.
The reason is that ath9k_htc *depends* on rs_more stuff because the
USB frames it receives *are* split up and to RX them we decouple
them. With this patch you'd break ath9k_htc considerably.
> Or saying that the patch is fine but another patch is needed on top?
My suggestion is that this change can be made but only on the
ath9k RX path, instead of the comon path so a separate patch would
be needed.
Luis
^ permalink raw reply
* Re: mac80211/ath9k: HT rates in Mesh
From: Luis R. Rodriguez @ 2010-05-04 19:52 UTC (permalink / raw)
To: Mathieu Olivari; +Cc: Luis Rodriguez, linux-wireless
In-Reply-To: <93781E992CBA7843962D8B0E7D683F3C1116C465EA@SC1EXMB-MBCL.global.atheros.com>
Cc'ing linux-wireless.
On Tue, May 04, 2010 at 12:45:36PM -0700, Mathieu Olivari wrote:
> BTW, do you know if HT is supported in Mesh ?
This would involve doing the same as for IBSS that Benoit
is doing, someone with good will would have to do it. It should
be fairly easy to review the patches implemented by Benoit to
port to Mesh but there may be some unresolved things I may be
overlooking.
Luis
^ permalink raw reply
* Re: [PATCH] ath9k: fix another source of corrupt frames
From: Luis R. Rodriguez @ 2010-05-04 19:55 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Luis Rodriguez, linux-wireless, John W. Linville
In-Reply-To: <4BE0773A.8090009@openwrt.org>
On Tue, May 04, 2010 at 12:36:26PM -0700, Felix Fietkau wrote:
> On 2010-05-04 8:09 PM, Luis R. Rodriguez wrote:
> > On Tue, May 4, 2010 at 12:58 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> >> Atheros hardware supports receiving frames that span multiple
> >> descriptors and buffers. In this case, the rx status of every
> >> descriptor except for the last one is invalid and may contain random
> >> data. Because the driver does not support this, it needs to drop such
> >> frames.
> >>
> >> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> >> ---
> >> --- a/drivers/net/wireless/ath/ath9k/common.c
> >> +++ b/drivers/net/wireless/ath/ath9k/common.c
> >> @@ -57,13 +57,19 @@ static bool ath9k_rx_accept(struct ath_c
> >> * rs_more indicates chained descriptors which can be used
> >> * to link buffers together for a sort of scatter-gather
> >> * operation.
> >> - *
> >> + * reject the frame, we don't support scatter-gather yet and
> >> + * the frame is probably corrupt anyway
> >> + */
> >> + if (rx_stats->rs_more)
> >> + return false;
> >
> > Actually this is required by ath9k_htc, it does process these, but
> > ath9k doesn't so this could be done within ath9k itself.
> I don't see any place in ath9k_htc that processes rs_more.
Odd, when I worked on it, I had to use this, let me check with today's
code and get back to this thread.
> And even if
> it did, processing the rx status of a frame that has more descriptors
> chained after it would be wrong, since the rx status is only valid for
> the last frame of the descriptor chain.
This is true.
> I think my patch would work fine for ath9k_htc as well.
We should test just to be sure. Would hate to request for a revert
for something we could have just prevented with proper testing/review.
I can test this in a bit I think.
Luis
^ permalink raw reply
* [PATCH] rtl8180: use SET_IEEE80211_PERM_ADDR
From: John W. Linville @ 2010-05-04 19:53 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8180_dev.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180_dev.c b/drivers/net/wireless/rtl818x/rtl8180_dev.c
index 4907fef..093b93d 100644
--- a/drivers/net/wireless/rtl818x/rtl8180_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180_dev.c
@@ -827,6 +827,7 @@ static int __devinit rtl8180_probe(struct pci_dev *pdev,
const char *chip_name, *rf_name = NULL;
u32 reg;
u16 eeprom_val;
+ u8 mac_addr[ETH_ALEN];
err = pci_enable_device(pdev);
if (err) {
@@ -987,12 +988,13 @@ static int __devinit rtl8180_probe(struct pci_dev *pdev,
eeprom_93cx6_read(&eeprom, 0x19, &priv->rfparam);
}
- eeprom_93cx6_multiread(&eeprom, 0x7, (__le16 *)dev->wiphy->perm_addr, 3);
- if (!is_valid_ether_addr(dev->wiphy->perm_addr)) {
+ eeprom_93cx6_multiread(&eeprom, 0x7, (__le16 *)mac_addr, 3);
+ if (!is_valid_ether_addr(mac_addr)) {
printk(KERN_WARNING "%s (rtl8180): Invalid hwaddr! Using"
" randomly generated MAC addr\n", pci_name(pdev));
- random_ether_addr(dev->wiphy->perm_addr);
+ random_ether_addr(mac_addr);
}
+ SET_IEEE80211_PERM_ADDR(dev, mac_addr);
/* CCK TX power */
for (i = 0; i < 14; i += 2) {
@@ -1024,7 +1026,7 @@ static int __devinit rtl8180_probe(struct pci_dev *pdev,
}
printk(KERN_INFO "%s: hwaddr %pM, %s + %s\n",
- wiphy_name(dev->wiphy), dev->wiphy->perm_addr,
+ wiphy_name(dev->wiphy), mac_addr,
chip_name, priv->rf->name);
return 0;
--
1.6.6.1
^ permalink raw reply related
* [PATCH] rtl8187: use SET_IEEE80211_PERM_ADDR
From: John W. Linville @ 2010-05-04 19:53 UTC (permalink / raw)
To: linux-wireless; +Cc: herton, htl10, Larry.Finger, John W. Linville
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/rtl818x/rtl8187_dev.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index 0fb850e..ef66a5e 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -1332,6 +1332,7 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
u16 txpwr, reg;
u16 product_id = le16_to_cpu(udev->descriptor.idProduct);
int err, i;
+ u8 mac_addr[ETH_ALEN];
dev = ieee80211_alloc_hw(sizeof(*priv), &rtl8187_ops);
if (!dev) {
@@ -1389,12 +1390,13 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
udelay(10);
eeprom_93cx6_multiread(&eeprom, RTL8187_EEPROM_MAC_ADDR,
- (__le16 __force *)dev->wiphy->perm_addr, 3);
- if (!is_valid_ether_addr(dev->wiphy->perm_addr)) {
+ (__le16 __force *)mac_addr, 3);
+ if (!is_valid_ether_addr(mac_addr)) {
printk(KERN_WARNING "rtl8187: Invalid hwaddr! Using randomly "
"generated MAC address\n");
- random_ether_addr(dev->wiphy->perm_addr);
+ random_ether_addr(mac_addr);
}
+ SET_IEEE80211_PERM_ADDR(dev, mac_addr);
channel = priv->channels;
for (i = 0; i < 3; i++) {
@@ -1525,7 +1527,7 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
skb_queue_head_init(&priv->b_tx_status.queue);
printk(KERN_INFO "%s: hwaddr %pM, %s V%d + %s, rfkill mask %d\n",
- wiphy_name(dev->wiphy), dev->wiphy->perm_addr,
+ wiphy_name(dev->wiphy), mac_addr,
chip_name, priv->asic_rev, priv->rf->name, priv->rfkill_mask);
#ifdef CONFIG_RTL8187_LEDS
--
1.6.6.1
^ permalink raw reply related
* Re: mac80211/ath9k: HT rates in Mesh
From: Johannes Berg @ 2010-05-04 20:14 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Mathieu Olivari, Luis Rodriguez, linux-wireless
In-Reply-To: <20100504195211.GG2624@tux>
On Tue, 2010-05-04 at 12:52 -0700, Luis R. Rodriguez wrote:
> Cc'ing linux-wireless.
>
> On Tue, May 04, 2010 at 12:45:36PM -0700, Mathieu Olivari wrote:
> > BTW, do you know if HT is supported in Mesh ?
>
> This would involve doing the same as for IBSS that Benoit
> is doing, someone with good will would have to do it. It should
> be fairly easy to review the patches implemented by Benoit to
> port to Mesh but there may be some unresolved things I may be
> overlooking.
Last I heard mesh wasn't supporting HT at all due to whatever issues?
Maybe protection or something?
johannes
^ permalink raw reply
* Re: mac80211/ath9k: HT rates in Mesh
From: Luis R. Rodriguez @ 2010-05-04 20:20 UTC (permalink / raw)
To: Johannes Berg, Javier Cardona
Cc: Luis Rodriguez, Mathieu Olivari, linux-wireless
In-Reply-To: <1273004047.3673.26.camel@jlt3.sipsolutions.net>
Adding Javier.
On Tue, May 04, 2010 at 01:14:07PM -0700, Johannes Berg wrote:
> On Tue, 2010-05-04 at 12:52 -0700, Luis R. Rodriguez wrote:
> > Cc'ing linux-wireless.
> >
> > On Tue, May 04, 2010 at 12:45:36PM -0700, Mathieu Olivari wrote:
> > > BTW, do you know if HT is supported in Mesh ?
> >
> > This would involve doing the same as for IBSS that Benoit
> > is doing, someone with good will would have to do it. It should
> > be fairly easy to review the patches implemented by Benoit to
> > port to Mesh but there may be some unresolved things I may be
> > overlooking.
>
> Last I heard mesh wasn't supporting HT at all due to whatever issues?
> Maybe protection or something?
Oh .. yeah... it was aggregation that was not allowed. So the only
other change you'd have to do is to disable aggregation IIRC unless
something else has changed on the latest 11s drafts.
Luis
^ permalink raw reply
* A file to print the release of loaded compat-wireless stuff
From: Luis R. Rodriguez @ 2010-05-04 20:44 UTC (permalink / raw)
To: linux-wireless
It seems there is a reasonable need to find out what version of
compat-wireless you have running. This will be a dated thing when
based on linux-next but more importantly it will contain the 2.6.3x.y
release the release was based on for the stable releases. Any ideas of
what filesystem API to use for this, I was thinking maybe a simple
sysfs entry for the compat module. Thoughts, preferences?
Luis
^ permalink raw reply
* Re: A file to print the release of loaded compat-wireless stuff
From: Pavel Roskin @ 2010-05-04 21:11 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <x2q43e72e891005041344gb9945d73p3d97e648fd13aa85@mail.gmail.com>
On Tue, 2010-05-04 at 13:44 -0700, Luis R. Rodriguez wrote:
> It seems there is a reasonable need to find out what version of
> compat-wireless you have running. This will be a dated thing when
> based on linux-next but more importantly it will contain the 2.6.3x.y
> release the release was based on for the stable releases. Any ideas of
> what filesystem API to use for this, I was thinking maybe a simple
> sysfs entry for the compat module. Thoughts, preferences?
We could use a read-only parameter of the compat module. Then the
version would be in /sys/module/compat/parameters/version
Module parameters are visible in sysfs even if the code is compiled into
the kernel.
--
Regards,
Pavel Roskin
^ permalink raw reply
* 2.6.34-rc6-git2: Reported regressions from 2.6.33
From: Rafael J. Wysocki @ 2010-05-04 20:49 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.33,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.33, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-05-04 76 26 22
2010-04-20 64 35 34
2010-04-07 48 35 33
2010-03-21 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15880
Subject : Very bad regression from 2.6.33 as of 1600f9def
Submitter : Alex Elsayed <eternaleye@gmail.com>
Date : 2010-04-29 2:28 (6 days old)
Message-ID : <loom.20100429T041908-663@post.gmane.org>
References : http://marc.info/?l=linux-kernel&m=127250825306178&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15863
Subject : 2.6.34-rc5-git7 (plus all patches) -- another suspicious rcu_dereference_check() usage.
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2010-04-27 0:51 (8 days old)
Message-ID : <h2ya44ae5cd1004261751waa5cb65ei3d139cbcfa2cc5cf@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127232949104878&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15862
Subject : 2.6.34-rc4/5: iwlagn unusable until reload
Submitter : Nico Schottelius <nico-linux-20100427@schottelius.org>
Date : 2010-04-27 7:49 (8 days old)
Message-ID : <20100427074934.GB3261@ikn.schottelius.org>
References : http://marc.info/?l=linux-kernel&m=127235784004839&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15858
Subject : [2.6.34-rc5] bad page state copying to/from HFS+ filesystem...
Submitter : Daniel J Blueman <daniel.blueman@gmail.com>
Date : 2010-04-25 21:14 (10 days old)
Message-ID : <v2k6278d2221004251414kbbcc41baw78b86120d81dce7d@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127223008621881&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15805
Subject : reiserfs locking
Submitter : Alexander Beregalov <a.beregalov@gmail.com>
Date : 2010-04-15 21:02 (20 days old)
Message-ID : <t2ka4423d671004151402n7b2dc425mdc9c6bb9640d63fb@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=127136535323933&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15790
Subject : Meta-Bug: Regressions
Submitter : Florian Mickler <fmickler@gmx.de>
Date : 2010-04-15 18:21 (20 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15788
Subject : external usb sound card doesn't work after resume
Submitter : François Valenduc <francois.valenduc@tvcablenet.be>
Date : 2010-04-15 10:16 (20 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15717
Subject : bluetooth oops
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-03-14 20:14 (52 days old)
Message-ID : <20100314201434.GE22059@elf.ucw.cz>
References : http://marc.info/?l=linux-kernel&m=126859771528426&w=4
Handled-By : Marcel Holtmann <marcel@holtmann.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15713
Subject : hackbench regression due to commit 9dfc6e68bfe6e
Submitter : Alex Shi <alex.shi@intel.com>
Date : 2010-03-25 8:40 (41 days old)
First-Bad-Commit: http://git.kernel.org/linus/9dfc6e68bfe6ee452efb1a4e9ca26a9007f2b864
Message-ID : <1269506457.4513.141.camel@alexs-hp.sh.intel.com>
References : http://marc.info/?l=linux-kernel&m=126950632920682&w=4
Handled-By : Christoph Lameter <cl@linux-foundation.org>
Pekka Enberg <penberg@cs.helsinki.fi>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15712
Subject : [regression] 2.6.34-rc1 to -rc3 on zaurus: no longer boots
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-04-01 6:06 (34 days old)
Message-ID : <20100401060624.GA1329@ucw.cz>
References : http://marc.info/?l=linux-kernel&m=127010200817402&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15704
Subject : [r8169] WARNING: at net/sched/sch_generic.c
Submitter : Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date : 2010-03-31 10:21 (35 days old)
Message-ID : <<20100331102142.GA3294@swordfish.minsk.epam.com>>
References : http://marc.info/?l=linux-kernel&m=127003090406108&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15673
Subject : 2.6.34-rc2: "ima_dec_counts: open/free imbalance"?
Submitter : Thomas Meyer <thomas@m3y3r.de>
Date : 2010-03-28 11:31 (38 days old)
Message-ID : <1269775909.5301.4.camel@localhost.localdomain>
References : http://marc.info/?l=linux-kernel&m=126977593326800&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15671
Subject : intel graphic card hanging (Hangcheck timer elapsed... GPU hung)
Submitter : Norbert Preining <preining@logic.at>
Date : 2010-03-27 16:11 (39 days old)
Message-ID : <20100327161104.GA12043@gamma.logic.tuwien.ac.at>
References : http://marc.info/?l=linux-kernel&m=126970883105262&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15669
Subject : INFO: suspicious rcu_dereference_check()
Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com>
Date : 2010-03-08 1:26 (58 days old)
Message-ID : <c4e36d111003250348q678eb2e6w4f3e8133e7fd6e58@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=126801163107713&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15664
Subject : Graphics hang and kernel backtrace when starting Azureus with Compiz enabled
Submitter : Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec>
Date : 2010-04-01 01:09 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15659
Subject : [Regresion] [2.6.34-rc1] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2010-03-25 20:04 (41 days old)
Message-ID : <<201003252104.24965.maciej.rutecki@gmail.com>>
References : http://marc.info/?l=linux-kernel&m=126954749618319&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15625
Subject : BUG: 2.6.34-rc1, RIP is (null)
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2010-03-18 22:22 (48 days old)
Message-ID : <4BA2A7A9.4080503@oracle.com>
References : http://marc.info/?l=linux-kernel&m=126895098217351&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15611
Subject : Failure with the 2.6.34-rc1 kernel
Submitter : Rupjyoti Sarmah <rsarmah@amcc.com>
Date : 2010-03-16 15:45 (50 days old)
Message-ID : <AC311A8E81420D4EBC1F26E6479848FE065B7D3D@SDCEXCHANGE01.ad.amcc.com>
References : http://marc.info/?l=linux-kernel&m=126875435718396&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15610
Subject : fsck leads to swapper - BUG: unable to handle kernel NULL pointer dereference & panic
Submitter : Ozgur Yuksel <ozgur.yuksel@oracle.com>
Date : 2010-03-22 15:59 (44 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15601
Subject : [BUG] SLOB breaks Crypto
Submitter : michael-dev@fami-braun.de
Date : 2010-03-15 13:39 (51 days old)
Message-ID : <4B9E38AF.70309@fami-braun.de>
References : http://marc.info/?l=linux-kernel&m=126866044724539&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15590
Subject : 2.6.34-rc1: regression: ^Z no longer stops sound
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-03-14 7:58 (52 days old)
Message-ID : <20100314075831.GA13457@elf.ucw.cz>
References : http://marc.info/?l=linux-kernel&m=126855353122623&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15589
Subject : 2.6.34-rc1: Badness at fs/proc/generic.c:316
Submitter : Christian Kujau <lists@nerdbynature.de>
Date : 2010-03-13 23:53 (53 days old)
Message-ID : <alpine.DEB.2.01.1003131544340.5493@bogon.housecafe.de>
References : http://marc.info/?l=linux-kernel&m=126852442903680&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15893
Subject : Alps: No edge-scrolling since 2.6.34-rc5
Submitter : Felix Zweig <f.zweig@yahoo.de>
Date : 2010-05-01 16:23 (4 days old)
Handled-By : Dan Carpenter <error27@gmail.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=26218
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15768
Subject : Incorrectly calculated free blocks result in ENOSPC from writepage
Submitter : Dmitry Monakhov <dmonakhov@openvz.org>
Date : 2010-04-12 11:24 (23 days old)
Handled-By : Dmitry Monakhov <dmonakhov@openvz.org>
Patch : http://patchwork.ozlabs.org/patch/49989/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15729
Subject : BUG: physmap modprobe & rmmod
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2010-04-02 20:40 (33 days old)
Message-ID : <20100402134058.c4682716.randy.dunlap@oracle.com>
References : http://marc.info/?l=linux-kernel&m=127024096210230&w=2
Handled-By : Hartley Sweeten <hsweeten@visionengravers.com>
Patch : https://patchwork.kernel.org/patch/90497/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15505
Subject : No more b43 wireless interface since 2.6.34-rc1
Submitter : Christian Casteyde <casteyde.christian@free.fr>
Date : 2010-03-10 06:59 (56 days old)
Handled-By : Yinghai Lu <yinghai@kernel.org>
Patch : https://bugzilla.kernel.org/show_bug.cgi?id=15505#c11
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.33,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=15310
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: [PATCH] rtl8187: use SET_IEEE80211_PERM_ADDR
From: Hin-Tak Leung @ 2010-05-04 21:33 UTC (permalink / raw)
To: linux-wireless, John W. Linville; +Cc: herton, Larry.Finger, John W. Linville
In-Reply-To: <1273002809-8595-1-git-send-email-linville@tuxdriver.com>
--- On Tue, 4/5/10, John W. Linville <linville@tuxdriver.com> wrote:
> Signed-off-by: John W. Linville
> <linville@tuxdriver.com>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Look likes a good direction of change to hide the wiphy details.
Hin-Tak
^ permalink raw reply
* Re: A file to print the release of loaded compat-wireless stuff
From: Luis R. Rodriguez @ 2010-05-04 21:51 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless
In-Reply-To: <1273007509.12618.1.camel@mj>
On Tue, May 4, 2010 at 2:11 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Tue, 2010-05-04 at 13:44 -0700, Luis R. Rodriguez wrote:
>> It seems there is a reasonable need to find out what version of
>> compat-wireless you have running. This will be a dated thing when
>> based on linux-next but more importantly it will contain the 2.6.3x.y
>> release the release was based on for the stable releases. Any ideas of
>> what filesystem API to use for this, I was thinking maybe a simple
>> sysfs entry for the compat module. Thoughts, preferences?
>
> We could use a read-only parameter of the compat module. Then the
> version would be in /sys/module/compat/parameters/version
>
> Module parameters are visible in sysfs even if the code is compiled into
> the kernel.
Neat trick thanks for the tip, will give that a shot.
Luis
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox