* Re: [Bug #13846] Possible regression in rt61pci driver
From: Rafael J. Wysocki @ 2009-08-03 19:17 UTC (permalink / raw)
To: chris2553; +Cc: Linux Kernel Mailing List, Kernel Testers List, linux-wireless
In-Reply-To: <200908031931.27427.chris2553@googlemail.com>
On Monday 03 August 2009, Chris Clayton wrote:
> Hi Rafael,
>
> On Sunday 02 August 2009, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.30. Please verify if it still should be listed and let me know
> > (either way).
> >
>
> The folks on the wireless project have concluded that the problem I reported is down to a hardware
> problem when power saving is switched on on for my Belkin cardbus wireless adapter, so now I simply
> turn power-saving off when wlan0 comes up. I did, however, ask whether anyone was going to fix the
> fact that once power-saving turns the LEDs off, they never come back on again, but I haven't had an
> answer. Is that a regression? I guess the answer is no, because power saving in the rt61pci driver
> is feature that is new to 2.6.31.
Well, IMO it is a regression, because it had worked before the power saving
feature was added.
> Should it be fixed? I think the answer is yes, but being unable to do it
> myself, I probably don't have a vote :-)
Well, if you remind the developers about the issue from time to time, it may
help. ;-)
Thanks,
Rafael
^ permalink raw reply
* [PATCH v2.6.31 resend] iwlagn: do not send key clear commands when rfkill enabled
From: Reinette Chatre @ 2009-08-03 19:10 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Reinette Chatre
From: Reinette Chatre <reinette.chatre@intel.com>
Do all key clearing except sending sommands to device when rfkill
enabled. When rfkill enabled the interface is brought down and will
be brought back up correctly after rfkill is enabled again.
Same change is not needed for iwl3945 as it ignores return code when
sending key clearing command to device.
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=13742
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Tested-by: Frans Pop <elendil@planet.nl>
---
This patch also targeted 2.6.31 but did not make it there and from what I
can tell it is not queued for it either. Could you please send it to
2.6.31?
drivers/net/wireless/iwlwifi/iwl-sta.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-sta.c b/drivers/net/wireless/iwlwifi/iwl-sta.c
index 2addf73..ffd5c61 100644
--- a/drivers/net/wireless/iwlwifi/iwl-sta.c
+++ b/drivers/net/wireless/iwlwifi/iwl-sta.c
@@ -566,6 +566,8 @@ int iwl_remove_default_wep_key(struct iwl_priv *priv,
unsigned long flags;
spin_lock_irqsave(&priv->sta_lock, flags);
+ IWL_DEBUG_WEP(priv, "Removing default WEP key: idx=%d\n",
+ keyconf->keyidx);
if (!test_and_clear_bit(keyconf->keyidx, &priv->ucode_key_table))
IWL_ERR(priv, "index %d not used in uCode key table.\n",
@@ -573,6 +575,11 @@ int iwl_remove_default_wep_key(struct iwl_priv *priv,
priv->default_wep_key--;
memset(&priv->wep_keys[keyconf->keyidx], 0, sizeof(priv->wep_keys[0]));
+ if (iwl_is_rfkill(priv)) {
+ IWL_DEBUG_WEP(priv, "Not sending REPLY_WEPKEY command due to RFKILL.\n");
+ spin_unlock_irqrestore(&priv->sta_lock, flags);
+ return 0;
+ }
ret = iwl_send_static_wepkey_cmd(priv, 1);
IWL_DEBUG_WEP(priv, "Remove default WEP key: idx=%d ret=%d\n",
keyconf->keyidx, ret);
@@ -853,6 +860,11 @@ int iwl_remove_dynamic_key(struct iwl_priv *priv,
priv->stations[sta_id].sta.sta.modify_mask = STA_MODIFY_KEY_MASK;
priv->stations[sta_id].sta.mode = STA_CONTROL_MODIFY_MSK;
+ if (iwl_is_rfkill(priv)) {
+ IWL_DEBUG_WEP(priv, "Not sending REPLY_ADD_STA command because RFKILL enabled. \n");
+ spin_unlock_irqrestore(&priv->sta_lock, flags);
+ return 0;
+ }
ret = iwl_send_add_sta(priv, &priv->stations[sta_id].sta, CMD_ASYNC);
spin_unlock_irqrestore(&priv->sta_lock, flags);
return ret;
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH] iwlwifi: avoid memory leak in iwl_dbgfs_nvm_read
From: reinette chatre @ 2009-08-03 19:08 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org, Martin Ettl
In-Reply-To: <1249325388-6496-1-git-send-email-linville@tuxdriver.com>
On Mon, 2009-08-03 at 11:49 -0700, John W. Linville wrote:
> Reported-by: Martin Ettl <ettl.martin@gmx.de>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/iwlwifi/iwl-debugfs.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-debugfs.c b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
> index 11e08c0..6525e41 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-debugfs.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
> @@ -318,7 +318,8 @@ static ssize_t iwl_dbgfs_nvm_read(struct file *file,
> ptr = priv->eeprom;
> if (!ptr) {
> IWL_ERR(priv, "Invalid EEPROM/OTP memory\n");
> - return -ENOMEM;
> + ret = -ENOMEM;
> + goto out;
> }
> pos += scnprintf(buf + pos, buf_size - pos, "NVM Type: %s\n",
> (priv->nvm_device_type == NVM_DEVICE_TYPE_OTP)
> @@ -333,6 +334,8 @@ static ssize_t iwl_dbgfs_nvm_read(struct file *file,
> }
>
> ret = simple_read_from_buffer(user_buf, count, ppos, buf, pos);
> +
> +out:
> kfree(buf);
> return ret;
> }
There was another patch also that was acked by Zhu Yi. See
http://thread.gmane.org/gmane.linux.kernel.wireless.general/37032
Reinette
^ permalink raw reply
* [PATCH] iwlwifi: avoid memory leak in iwl_dbgfs_nvm_read
From: John W. Linville @ 2009-08-03 18:49 UTC (permalink / raw)
To: linux-wireless; +Cc: Martin Ettl, John W. Linville
Reported-by: Martin Ettl <ettl.martin@gmx.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-debugfs.c b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
index 11e08c0..6525e41 100644
--- a/drivers/net/wireless/iwlwifi/iwl-debugfs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
@@ -318,7 +318,8 @@ static ssize_t iwl_dbgfs_nvm_read(struct file *file,
ptr = priv->eeprom;
if (!ptr) {
IWL_ERR(priv, "Invalid EEPROM/OTP memory\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
}
pos += scnprintf(buf + pos, buf_size - pos, "NVM Type: %s\n",
(priv->nvm_device_type == NVM_DEVICE_TYPE_OTP)
@@ -333,6 +334,8 @@ static ssize_t iwl_dbgfs_nvm_read(struct file *file,
}
ret = simple_read_from_buffer(user_buf, count, ppos, buf, pos);
+
+out:
kfree(buf);
return ret;
}
--
1.6.2.5
^ permalink raw reply related
* Re: [Bug #13846] Possible regression in rt61pci driver
From: Chris Clayton @ 2009-08-03 18:31 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, linux-wireless
In-Reply-To: <iZB3Pj-uj3M.A.pRC.1cgdKB@chimera>
Hi Rafael,
On Sunday 02 August 2009, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.30. Please verify if it still should be listed and let me know
> (either way).
>
The folks on the wireless project have concluded that the problem I reported is down to a hardware
problem when power saving is switched on on for my Belkin cardbus wireless adapter, so now I simply
turn power-saving off when wlan0 comes up. I did, however, ask whether anyone was going to fix the
fact that once power-saving turns the LEDs off, they never come back on again, but I haven't had an
answer. Is that a regression? I guess the answer is no, because power saving in the rt61pci driver
is feature that is new to 2.6.31. Should it be fixed? I think the answer is yes, but being unable
to do it myself, I probably don't have a vote :-)
All I can do is report that I now know how to avoid my laptop freezing and leave the decision as to
whether it should stay on the regression list to you and the folks from the wireless project.
Thanks,
Chris
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13846
> Subject : Possible regression in rt61pci driver
> Submitter : Chris Clayton <chris2553@googlemail.com>
> Date : 2009-07-13 8:27 (21 days old)
> References : http://marc.info/?l=linux-kernel&m=124747418828398&w=4
--
No, Sir; there is nothing which has yet been contrived by man, by which so much happiness is
produced as by a good tavern or inn - Doctor Samuel Johnson
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 4/4] ath5k: Use SWI to trigger calibration
From: Nick Kossifidis @ 2009-08-03 17:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jiri Slaby, linux-wireless, ath5k-devel, linville
In-Reply-To: <1249115316.2007.0.camel@johannes.local>
2009/8/1 Johannes Berg <johannes@sipsolutions.net>:
> On Sat, 2009-08-01 at 10:24 +0200, Jiri Slaby wrote:
>> On 08/01/2009 10:21 AM, Johannes Berg wrote:
>> > Actually, jiffies are unsigned long
>>
>> Yeah, this is what I meant. I agree I messed it up when I didn't write
>> the unsigned explicitly. It might have been confusing, thanks for
>> pointing out.
>
> And, in addition to what you said, the code shouldn't divide jiffies, it
> should multiply the timeout, add it to the start time, and then use
> time_is_after_jiffies() or so.
>
> johannes
ACK will resend asap ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: [PATCH 1/1] rfkill: add the GPS radio type
From: Marcel Holtmann @ 2009-08-03 17:02 UTC (permalink / raw)
To: Tomas Winkler; +Cc: Johannes Berg, linville, linux-wireless
In-Reply-To: <1ba2fa240908030953w3dd40803l1e135cb73ee1cff@mail.gmail.com>
Hi Tomas,
> >> >> > > we don't have a GPS subsystem, but even without it, I think this is a
> >> >> > > good thing to have.
> >> >> >
> >> >> > GPS devices are usually serial devices.
> >> >>
> >> >> Yeah, this is interesting -- do we want something like /dev/urfkill
> >> >> (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same
> >> >> applies for 3G) can be controlled with rfkill?
> >> >
> >> > on one hand I think urfkill might be needed, on the other hand I think
> >> > we should not do it at all. Currently I would think it is better to
> >> > force the RFKILL integration in the kernel so that we have proper
> >> > subsystem integration, or platform RFKILL switches or in cases like GPS
> >> > and WWAN/3G it will be driver integration. For 3G we already have the
> >> > hso.ko driver which has a killswitch and we just need to fix the other
> >> > ones. I am actually looking into it, if this is possible without an AT
> >> > parser inside the kernel.
> >>
> >> >
> >> > So the GPS world is evolving right now and that everybody implements
> >> > them as kernel-tty-passthrough pseudo driver and then a binary only
> >> > daemon and then gpsd/gypsy on top of it will only survive for certain
> >> > amount of time. The binary component will not get wide acceptance. And
> >> > even if the binary only userspace component stays, we might still need a
> >> > proper GPS subsystem since using TTY as pure transport is holding us
> >> > back. Could be that AF_GPS would have been a way better choice. This
> >> > will sort itself out over time.
> >> >
> >>
> >> BT also fails to the same category. BT driver also just servers as HCI
> >> transport layer.
> >> Current implementation of closing device driver is not sufficient to
> >> really bring the device to rfkill mode. My point is from multi com
> >> devices. What vendor implements are proprietary HCI commands that
> >> brings device to rfkill mode, there is no standard. So in general you
> >> would need HCI parser similar to AT parser or NMEA GPS parser The
> >> rfkill event is transferred inside the transport not visible to device
> >> driver.
> >> In other words RFKILL is happening between device and application w/o
> >> kernel intervention. This is a problem since usually user application
> >> and kernel has to be somehow notified.
> >
> > I have no idea what you are talking about here. The Bluetooth RFKILL
> > does exactly the right thing. The driver gets the down callback and is
> > responsible to bring the device down. It is expected that the radio will
> > be brought down at that point.
>
> Let say you have USB device with 2 ports BT and Wifi Closing prot
> just releases urbs but it doesn't tell to particular port to shut the
> radio it has no means for that., you have wifi running in parallel
> playing with the radio its BT/WIFI coexistent games it has no
> knowledge about rfkill event. In SDIO things are little better since
> you call sdio_disable_func() but you only guessing that device will
> interpret it as rfkill as well.
this is a problem of the firmware inside the device. And if it is USB,
it could just have proper vendor specific control URBs that allow you to
control the radio RFKILL capabilities. If you happen to have a device
that has no notion of RFKILL at all, then that is just bad luck.
In embedded systems you can also have platform RFKILL switches that
toggle directly the power state via a GPIO. This is what we call a hard
killswitch. The subsystem integrated switches are softkill switches.
> >> Frankly I still don't understand what flow of how /dev/uevent is
> >> helpful here. Who is notifying whom about rfkill event.
> >
> > Starting with 2.6.31 kernel we are using /dev/rfkill for notification
> > about RFKILL state changes. Previously it was done via uevents, but that
> > was more broken than helpful.
>
> So how /dev/rfkill differs from /dev/urfkill ?
I did explain that in the other email. We only have /dev/rfkill right
now and it might stay this way. The /dev/urfkill would be a way to
implement an RFKILL switch from within userspace.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/1] rfkill: add the GPS radio type
From: Tomas Winkler @ 2009-08-03 16:53 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Johannes Berg, linville, linux-wireless
In-Reply-To: <1249316678.3094.4.camel@localhost.localdomain>
On Mon, Aug 3, 2009 at 7:24 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
> Hi Tomas,
>
>> >> > > we don't have a GPS subsystem, but even without it, I think this is a
>> >> > > good thing to have.
>> >> >
>> >> > GPS devices are usually serial devices.
>> >>
>> >> Yeah, this is interesting -- do we want something like /dev/urfkill
>> >> (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same
>> >> applies for 3G) can be controlled with rfkill?
>> >
>> > on one hand I think urfkill might be needed, on the other hand I think
>> > we should not do it at all. Currently I would think it is better to
>> > force the RFKILL integration in the kernel so that we have proper
>> > subsystem integration, or platform RFKILL switches or in cases like GPS
>> > and WWAN/3G it will be driver integration. For 3G we already have the
>> > hso.ko driver which has a killswitch and we just need to fix the other
>> > ones. I am actually looking into it, if this is possible without an AT
>> > parser inside the kernel.
>>
>> >
>> > So the GPS world is evolving right now and that everybody implements
>> > them as kernel-tty-passthrough pseudo driver and then a binary only
>> > daemon and then gpsd/gypsy on top of it will only survive for certain
>> > amount of time. The binary component will not get wide acceptance. And
>> > even if the binary only userspace component stays, we might still need a
>> > proper GPS subsystem since using TTY as pure transport is holding us
>> > back. Could be that AF_GPS would have been a way better choice. This
>> > will sort itself out over time.
>> >
>>
>> BT also fails to the same category. BT driver also just servers as HCI
>> transport layer.
>> Current implementation of closing device driver is not sufficient to
>> really bring the device to rfkill mode. My point is from multi com
>> devices. What vendor implements are proprietary HCI commands that
>> brings device to rfkill mode, there is no standard. So in general you
>> would need HCI parser similar to AT parser or NMEA GPS parser The
>> rfkill event is transferred inside the transport not visible to device
>> driver.
>> In other words RFKILL is happening between device and application w/o
>> kernel intervention. This is a problem since usually user application
>> and kernel has to be somehow notified.
>
> I have no idea what you are talking about here. The Bluetooth RFKILL
> does exactly the right thing. The driver gets the down callback and is
> responsible to bring the device down. It is expected that the radio will
> be brought down at that point.
Let say you have USB device with 2 ports BT and Wifi Closing prot
just releases urbs but it doesn't tell to particular port to shut the
radio it has no means for that., you have wifi running in parallel
playing with the radio its BT/WIFI coexistent games it has no
knowledge about rfkill event. In SDIO things are little better since
you call sdio_disable_func() but you only guessing that device will
interpret it as rfkill as well.
>> Frankly I still don't understand what flow of how /dev/uevent is
>> helpful here. Who is notifying whom about rfkill event.
>
> Starting with 2.6.31 kernel we are using /dev/rfkill for notification
> about RFKILL state changes. Previously it was done via uevents, but that
> was more broken than helpful.
So how /dev/rfkill differs from /dev/urfkill ?
Thanks
Tomas
^ permalink raw reply
* Re: [PATCH 1/1] rfkill: add the GPS radio type
From: Marcel Holtmann @ 2009-08-03 16:24 UTC (permalink / raw)
To: Tomas Winkler; +Cc: Johannes Berg, linville, linux-wireless
In-Reply-To: <1ba2fa240908030723g634f222dn6d1b02e4d683b4d5@mail.gmail.com>
Hi Tomas,
> >> > > we don't have a GPS subsystem, but even without it, I think this is a
> >> > > good thing to have.
> >> >
> >> > GPS devices are usually serial devices.
> >>
> >> Yeah, this is interesting -- do we want something like /dev/urfkill
> >> (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same
> >> applies for 3G) can be controlled with rfkill?
> >
> > on one hand I think urfkill might be needed, on the other hand I think
> > we should not do it at all. Currently I would think it is better to
> > force the RFKILL integration in the kernel so that we have proper
> > subsystem integration, or platform RFKILL switches or in cases like GPS
> > and WWAN/3G it will be driver integration. For 3G we already have the
> > hso.ko driver which has a killswitch and we just need to fix the other
> > ones. I am actually looking into it, if this is possible without an AT
> > parser inside the kernel.
>
> >
> > So the GPS world is evolving right now and that everybody implements
> > them as kernel-tty-passthrough pseudo driver and then a binary only
> > daemon and then gpsd/gypsy on top of it will only survive for certain
> > amount of time. The binary component will not get wide acceptance. And
> > even if the binary only userspace component stays, we might still need a
> > proper GPS subsystem since using TTY as pure transport is holding us
> > back. Could be that AF_GPS would have been a way better choice. This
> > will sort itself out over time.
> >
>
> BT also fails to the same category. BT driver also just servers as HCI
> transport layer.
> Current implementation of closing device driver is not sufficient to
> really bring the device to rfkill mode. My point is from multi com
> devices. What vendor implements are proprietary HCI commands that
> brings device to rfkill mode, there is no standard. So in general you
> would need HCI parser similar to AT parser or NMEA GPS parser The
> rfkill event is transferred inside the transport not visible to device
> driver.
> In other words RFKILL is happening between device and application w/o
> kernel intervention. This is a problem since usually user application
> and kernel has to be somehow notified.
I have no idea what you are talking about here. The Bluetooth RFKILL
does exactly the right thing. The driver gets the down callback and is
responsible to bring the device down. It is expected that the radio will
be brought down at that point.
> Frankly I still don't understand what flow of how /dev/uevent is
> helpful here. Who is notifying whom about rfkill event.
Starting with 2.6.31 kernel we are using /dev/rfkill for notification
about RFKILL state changes. Previously it was done via uevents, but that
was more broken than helpful.
Regards
Marcel
^ permalink raw reply
* Re: 2.6.31-rc5: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-08-03 16:09 UTC (permalink / raw)
To: Johannes Weiner
Cc: Linus Torvalds, Linux Kernel Mailing List, Adrian Bunk,
Andrew Morton, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI, Mikael Pettersson
In-Reply-To: <20090803143108.GA12041@cmpxchg.org>
On Monday 03 August 2009, Johannes Weiner wrote:
> On Sun, Aug 02, 2009 at 03:22:01PM -0700, Linus Torvalds wrote:
>
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13815
> > > Subject : emacs -nw compilation doesn't show the error message
> > > Submitter : Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > > Date : 2009-07-23 06:22 (11 days old)
> > > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d945cb9cce20ac7143c2de8d88b187f62db99bdc
> >
> > Same old pty bug, same fix: commit e043e42bdb.
> >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13813
> > > Subject : Hangups in n_tty_read()
> > > Submitter : Johannes Weiner <hannes@cmpxchg.org>
> > > Date : 2009-07-16 18:48 (18 days old)
> > > References : http://marc.info/?l=linux-kernel&m=124777019920579&w=4
> >
> > Hmm. Worth testing that same fix, although the symptoms here are not
> > exactly the same.
>
> Hm, I had no debugging enabled, but I think a silent hang in
>
> pty_write()
> tty_flip_buffer_push()
> flush_to_ldisc()
>
> can cause the receiving side
>
> tty_read()
> n_tty_read()
>
> to wait forever for updates. I haven't looked closely. It seems to
> be gone with your latest master in any case.
Thanks, closed (in fact I closed it earlier already).
Rafael
^ permalink raw reply
* Re: 2.6.31-rc5: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-08-03 15:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI, Mikael Pettersson
In-Reply-To: <alpine.LFD.2.01.0908021456430.3352@localhost.localdomain>
On Monday 03 August 2009, Linus Torvalds wrote:
>
> On Sun, 2 Aug 2009, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13896
> > Subject : 2.6.31-rc4 broke expect and gcc's testsuite
> > Submitter : Mikael Pettersson <mikpe@it.uu.se>
> > Date : 2009-07-29 11:00 (5 days old)
> > References : http://marc.info/?l=linux-kernel&m=124885806406520&w=4
>
> I bet this is the same tty bug that got fixed by Ogawa in commit
> e043e42bdb. -rc5 has that fix. Mikael?
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13842
> > Subject : Oops when writing to /sys/block/ram0/queue/max_sectors_kb
> > Submitter : Jens Rosenboom <jens@mcbone.net>
> > Date : 2009-07-23 15:30 (11 days old)
> > References : http://marc.info/?l=linux-kernel&m=124836574403032&w=4
>
> Commit a4e7d46407d73f35d217013b363b79a8f8eafcaa fixed this one.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13826
> > Subject : thinkpad boots with backlight low
> > Submitter : Pavel Machek <pavel@ucw.cz>
> > Date : 2009-07-15 15:13 (19 days old)
> > References : http://marc.info/?l=linux-kernel&m=124756359126830&w=4
> > Handled-By : Henrique de Moraes Holschuh <hmh@hmh.eng.br>
>
> This should be commit 59fe4fe34d7afdf63208124f313be9056feaa2f4.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13815
> > Subject : emacs -nw compilation doesn't show the error message
> > Submitter : Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > Date : 2009-07-23 06:22 (11 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d945cb9cce20ac7143c2de8d88b187f62db99bdc
>
> Same old pty bug, same fix: commit e043e42bdb.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13813
> > Subject : Hangups in n_tty_read()
> > Submitter : Johannes Weiner <hannes@cmpxchg.org>
> > Date : 2009-07-16 18:48 (18 days old)
> > References : http://marc.info/?l=linux-kernel&m=124777019920579&w=4
>
> Hmm. Worth testing that same fix, although the symptoms here are not
> exactly the same.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13812
> > Subject : Ooops on uplug
> > Submitter : Daniel Mack <daniel@caiaq.de>
> > Date : 2009-07-20 17:51 (14 days old)
> > References : http://marc.info/?l=linux-kernel&m=124811234302786&w=4
> > Handled-By : Alan Stern <stern@rowland.harvard.edu>
> > Alan Cox <alan@linux.intel.com>
>
> Commit c56d3000861 should fix this.
>
> > Regressions with patches
> > ------------------------
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13891
> > Subject : PCI resources allocation problem on HP nx6325
> > Submitter : Rafael J. Wysocki <rjw@sisk.pl>
> > Date : 2009-08-02 13:37 (1 days old)
> > Handled-By : Linus Torvalds <torvalds@linux-foundation.org>
> > Patch : http://patchwork.kernel.org/patch/38774/
>
> Ok, this is committed as 79896cf42f6a96d7e14f2dc3473443d68d74031d.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13825
> > Subject : eeepc-laptop: fix hot-unplug on resume
> > Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> > Date : 2009-06-29 13:12 (35 days old)
> > References : http://lkml.org/lkml/2009/6/29/150
> > Handled-By : Alan Jenkins <alan-jenkins@tuffmail.co.uk>
> > Patch : http://patchwork.kernel.org/patch/32926/
>
> commit 7334546a52c6764df120459509b1f803a073eacc
Thanks a lot!
All closed except for http://bugzilla.kernel.org/show_bug.cgi?id=13813.
Best,
Rafael
^ permalink raw reply
* Re: A station can't reconnect after it wakes up
From: Igor Perminov @ 2009-08-03 15:22 UTC (permalink / raw)
To: hostap, linux-wireless; +Cc: Jouni Malinen, Artur Skawina
In-Reply-To: <4A7318E6.3000004@gmail.com>
On Fri, 31/07/2009 at 18:16 +0200, Artur Skawina wrote:
> [linux-wireless added to cc list]
>
> Igor Perminov wrote:
> > I have an issue related to handling power-saving stations by hostapd
> > and/or mac80211 stack. A station can't reconnect after it wakes up.
> >
> > The problems looks similar to another one having been reported to this
> > list earlier (STA can connect, but fails to reconnect within
> > ap_max_inactivity):
> > http://lists.shmoo.com/pipermail/hostap/2009-February/019192.html
> >
> > AP: Linux box with D-Link DWA-110 USB Wi-Fi stick (rt73usb kernel
> > driver), kernel 2.6.30 with some patches, hostapd 0.6.9.
> > Station: Toshiba G900 PDA under Windows Mobile 6.0.
> >
> > The environment is described in details here:
> > http://rt2x00.serialmonkey.com/phpBB/viewtopic.php?f=5&t=5486&start=10
> >
> > Consider the following step-by-step:
> > 1. A station authenticates and associates with the AP and exchanges
> > traffic.
> > 2. The station indicates to the AP that it is going to sleep.
> > 3. The station device goes to the stand-by mode (not only its wi-fi
> > card, but the device itself).
> > 4. The station device wakes up and begins authentication with an
> > Authentication management frame.
> >
> > This is the behavior of my PDA.
> >
> > The problem is the mac80211 stack at the point 4 "remembers" that the
> > station has gone to sleep. So, the response frames from hostapd are
> > buffered by mac80211.
> > The station indicates in the Authentication frame that it isn't sleeping
> > anymore. But the mac80211 stack analyzes sleep/wake transitions in
> > _data_ frames only, but not in management ones. See
> > ieee80211_rx_h_sta_process in net/mac80211/rx.c. A comment there notes:
> > "Ignore doze->wake transitions that are indicated by non-data frames,
> > the standard is unclear here".
> > As the result, the station never receives the authentication response
> > from the AP.
> >
> > One solution against this problem could be implemented in hostapd: to
> > force the mac80211 stack to "forget" the station just after receiving an
> > authentication frame (the patch is below). After this change the station
> > can reconnect successfully.
>
> i just did a quick test and your hostapd patch does indeed fix my problem
> too (p54+hostapd with a winmobile device that couldn't reconnect after
> turning the wifi module off and on).
>
> > Another solution (in theory) would be to improve the mac80211
> > implementation: to analyze not only data frames, but also
> > management ones (or may be just some kinds of them) in
> > ieee80211_rx_h_sta_process.
>
> would seem to make sense, but having not read the spec i have no idea
> if that's the right answer; hence the linux-wireless cc...
>
> > I've asked this question to the linux-wireless mailing list few days
> > ago, but nobody has answered still:
> > http://marc.info/?l=linux-wireless&m=124879549212741&w=2
> >
> > And what is your opinion, what is a better way: should this problem be
> > fixed in hostapd or in mac80211?
> >
> > === Begin diff ===
> > --- a/hostapd/ieee802_11.c 2009-06-29 14:21:59.000000000 +0400
> > +++ b/hostapd/ieee802_11.c 2009-07-21 16:28:17.000000000 +0400
> > @@ -583,6 +583,13 @@
> > goto fail;
> > }
> >
> > + res = hostapd_sta_remove(hapd, mgmt->sa);
> > + if (res) {
> > + wpa_printf(MSG_DEBUG, "authentication: STA=" MACSTR
> > + ", hostapd_sta_remove returned %d\n",
> > + MAC2STR(mgmt->sa), res);
> > + }
> > +
> > if (vlan_id > 0) {
> > if (hostapd_get_vlan_id_ifname(hapd->conf->vlan,
> > sta->vlan_id) == NULL) {
> > === End diff ===
>
> Thanks for the cc, added this to my local hostapd patch set, until the
> issue gets resolved one way or another.
>
> artur
I've looked through the 802-11.2007 document and now I consider the
source of the problem is misunderstanding by an AP and a STA states of
each other. When the station tries to reconnect it considers itself
non-authenticated. Whereas the AP considers the station both
authenticated and associated.
I think it would be better to fix the problem in hostapd, because it's a
hostapd's responsibility - to manage the state of a station being known
to the AP. So, when hostapd receives an Auth frame from a station it
should consider the station being non-authenticated and force removing
the station from the underlying stack.
I'll submit a patch for hostapd in a nearest future.
Best regards,
Igor
^ permalink raw reply
* Re: 2.6.31-rc5: Reported regressions 2.6.29 -> 2.6.30
From: Luis R. Rodriguez @ 2009-08-03 15:16 UTC (permalink / raw)
To: Rafael J. Wysocki, rootkit85
Cc: Linux Kernel Mailing List, Andrew Morton, Linus Torvalds,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <upey9ZSfnaF.A.-oE.rpgdKB@chimera>
Here are the wireless ones:
On Sun, Aug 2, 2009 at 12:06 PM, Rafael J. Wysocki<rjw@sisk.pl> wrote:
> Unresolved regressions
> ----------------------
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898
> Subject : Intel 3945ABG - problems on 2.6.30.X
> Submitter : dienet <dienet@poczta.fm>
> Date : 2009-07-31 15:17 (3 days old)
> References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638
> Subject : rt2870 driver is broken for (some) cards
> Submitter : jakob gruber <jakob.gruber@kabelnet.at>
> Date : 2009-06-27 17:33 (37 days old)
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581
> Subject : ath9k doesn't work with newer kernels
> Submitter : Matteo <rootkit85@yahoo.it>
> Date : 2009-06-19 12:04 (45 days old)
Issue looks more like a the user has rfkill enabled rather than a
driver issue. Waiting on user feedback since 2009-07-27.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362
> Subject : rt2x00: slow wifi with correct basic rate bitmap
> Submitter : Alejandro Riveira <ariveira@gmail.com>
> Date : 2009-05-22 13:32 (73 days old)
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13337
> Subject : [post 2.6.29 regression] hang during suspend of b44/b43 modules
> Submitter : Tomas Janousek <tomi@nomi.cz>
> Date : 2009-05-18 10:59 (77 days old)
> Handled-By : Johannes Berg <johannes@sipsolutions.net>
> Patch : http://patchwork.kernel.org/patch/37837/
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319
> Subject : Page allocation failures with b43 and p54usb
> Submitter : Larry Finger <Larry.Finger@lwfinger.net>
> Date : 2009-04-29 21:01 (96 days old)
> References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
> http://lkml.org/lkml/2009/6/7/136
> http://lkml.org/lkml/2009/7/26/213
> Handled-By : Johannes Berg <johannes@sipsolutions.net>
> David Rientjes <rientjes@google.com>
> Patch : http://patchwork.kernel.org/patch/37655/
^ permalink raw reply
* Re: Unsupported PHY on B43
From: Luis R. Rodriguez @ 2009-08-03 15:05 UTC (permalink / raw)
To: Luis Correia; +Cc: Johannes Berg, Michael Buesch, linux-wireless
In-Reply-To: <efe7343f0908020237k61fa7656s458cee0217b46c69@mail.gmail.com>
On Sun, Aug 2, 2009 at 2:37 AM, Luis Correia<luis.f.correia@gmail.com> wrote:
> On Sun, Aug 2, 2009 at 10:33, Johannes Berg<johannes@sipsolutions.net> wrote:
>> On Sun, 2009-08-02 at 10:26 +0100, Luis Correia wrote:
>>
>>> > This is an 11n phy.
>>>
>>> Great, an 11n device with only two antennas (they are usually three).
>>
>> Oh, it depends on the configuration -- maybe they used a cheaper device
>> with fewer chains.
>
> yes, it even is a half-height minipci-express card, the first one I've
> seen so far.
11n does not require three antennas. It really depends on the number
of streams you have and the chain configuration. As a matter of fact
you can use 11n with 1 stream and only use the lower MCS rates.
>>> >> I'm available to test drivers, patches, git kernels, the whole lot.
>>> >
>>> > There's nothing available beyond what you have.
>>>
>>> Bummer, I guess I'll have to wait then.
>>
>> Don't hold your breath -- nobody's working on it. I also really want it
>> working, but since nobody seems even interested in writing the driver,
>> we've halted the reverse engineering effort.
>
> 11n is doomed on Linux :(
No its not.
Luis
^ permalink raw reply
* [PATCH] cfg80211: clear SSID on disconnect
From: Johannes Berg @ 2009-08-03 15:03 UTC (permalink / raw)
To: John Linville; +Cc: Joerg Albert, linux-wireless
The SME state machine in cfg80211 uses the SSID stored
in struct wireless_dev internally, but fails to clear
it when disconnecting. This doesn't matter to the SME
state machine, but does matter for IBSS. Thus, when
disconnecting, clear the SSID to avoid messing up the
IBSS state machine.
Reported-by: Joerg Albert <jal2@gmx.de>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/sme.c | 1 +
1 file changed, 1 insertion(+)
--- wireless-testing.orig/net/wireless/sme.c 2009-08-03 16:45:01.000000000 +0200
+++ wireless-testing/net/wireless/sme.c 2009-08-03 16:59:02.000000000 +0200
@@ -550,6 +550,7 @@ void __cfg80211_disconnected(struct net_
wdev->current_bss = NULL;
wdev->sme_state = CFG80211_SME_IDLE;
+ wdev->ssid_len = 0;
if (wdev->conn) {
kfree(wdev->conn->ie);
^ permalink raw reply
* Re: 2.6.31-rc5: Reported regressions from 2.6.30
From: Johannes Weiner @ 2009-08-03 14:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Adrian Bunk,
Andrew Morton, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI, Mikael Pettersson
In-Reply-To: <alpine.LFD.2.01.0908021456430.3352@localhost.localdomain>
On Sun, Aug 02, 2009 at 03:22:01PM -0700, Linus Torvalds wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13815
> > Subject : emacs -nw compilation doesn't show the error message
> > Submitter : Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > Date : 2009-07-23 06:22 (11 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d945cb9cce20ac7143c2de8d88b187f62db99bdc
>
> Same old pty bug, same fix: commit e043e42bdb.
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13813
> > Subject : Hangups in n_tty_read()
> > Submitter : Johannes Weiner <hannes@cmpxchg.org>
> > Date : 2009-07-16 18:48 (18 days old)
> > References : http://marc.info/?l=linux-kernel&m=124777019920579&w=4
>
> Hmm. Worth testing that same fix, although the symptoms here are not
> exactly the same.
Hm, I had no debugging enabled, but I think a silent hang in
pty_write()
tty_flip_buffer_push()
flush_to_ldisc()
can cause the receiving side
tty_read()
n_tty_read()
to wait forever for updates. I haven't looked closely. It seems to
be gone with your latest master in any case.
Hannes
^ permalink raw reply
* Re: ar9170usb crashes during iwconfig for ad-hoc mode
From: Johannes Berg @ 2009-08-03 14:25 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless
In-Reply-To: <20090803123642.242160@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
On Mon, 2009-08-03 at 14:36 +0200, Joerg Albert wrote:
>
> > On Mon, 2009-08-03 at 10:44 +0200, Johannes Berg wrote:
> >
> > > > > ifconfig wlan1 down
> > > > > iwconfig wlan1 mode managed essid huhu
> > > > > ifconfig wlan1 up
> > > > > ifconfig wlan1 down
> > > > > iwconfig wlan1 mode ad-hoc essid huhu_a channel 1
> >
> > > No, it's a bug in cfg80211 :)
> >
> > But it's not making sense to me. I'll have to try to reproduce it. In
> > any case, we shouldn't be calling in to mac80211 from cfg80211 while the
> > interface is down.
>
> I guess this is caused by the call to __cfg80211_leave_ibss()
> in net/wireless/ibss.c::cfg80211_ibss_wext_siwfreq() trying to
> disable the beacon via net/mac80211::ieee80211_ibss_leave().
But it only does that if (wdev->ssid_len) which should be false, so I'm
confused.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] rfkill: add the GPS radio type
From: Tomas Winkler @ 2009-08-03 14:23 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Johannes Berg, linville, linux-wireless
In-Reply-To: <1249230503.3491.43.camel@localhost.localdomain>
On Sun, Aug 2, 2009 at 7:28 PM, Marcel Holtmann<marcel@holtmann.org> wrote:
> Hi Johannes,
>
>> > > we don't have a GPS subsystem, but even without it, I think this is a
>> > > good thing to have.
>> >
>> > GPS devices are usually serial devices.
>>
>> Yeah, this is interesting -- do we want something like /dev/urfkill
>> (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same
>> applies for 3G) can be controlled with rfkill?
>
> on one hand I think urfkill might be needed, on the other hand I think
> we should not do it at all. Currently I would think it is better to
> force the RFKILL integration in the kernel so that we have proper
> subsystem integration, or platform RFKILL switches or in cases like GPS
> and WWAN/3G it will be driver integration. For 3G we already have the
> hso.ko driver which has a killswitch and we just need to fix the other
> ones. I am actually looking into it, if this is possible without an AT
> parser inside the kernel.
>
> So the GPS world is evolving right now and that everybody implements
> them as kernel-tty-passthrough pseudo driver and then a binary only
> daemon and then gpsd/gypsy on top of it will only survive for certain
> amount of time. The binary component will not get wide acceptance. And
> even if the binary only userspace component stays, we might still need a
> proper GPS subsystem since using TTY as pure transport is holding us
> back. Could be that AF_GPS would have been a way better choice. This
> will sort itself out over time.
>
BT also fails to the same category. BT driver also just servers as HCI
transport layer.
Current implementation of closing device driver is not sufficient to
really bring the device to rfkill mode. My point is from multi com
devices. What vendor implements are proprietary HCI commands that
brings device to rfkill mode, there is no standard. So in general you
would need HCI parser similar to AT parser or NMEA GPS parser The
rfkill event is transferred inside the transport not visible to device
driver.
In other words RFKILL is happening between device and application w/o
kernel intervention. This is a problem since usually user application
and kernel has to be somehow notified.
Frankly I still don't understand what flow of how /dev/uevent is
helpful here. Who is notifying whom about rfkill event.
Thanks
Tomas
^ permalink raw reply
* Re: [PATCH RESEND] b43: implement baseband init for LP-PHY <= rev1
From: Gábor Stefanik @ 2009-08-03 13:55 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, linux-wireless, Larry Finger
In-Reply-To: <200908031115.12929.mb@bu3sch.de>
On Mon, Aug 3, 2009 at 11:15 AM, Michael Buesch<mb@bu3sch.de> wrote:
> On Monday 03 August 2009 11:13:37 Michael Buesch wrote:
>> On Monday 03 August 2009 00:18:22 Gábor Stefanik wrote:
>> > Implement baseband init for rev.0 and rev.1 LP PHYs. Convert
>> > boardflags_hi values to defines.
>> > Implement b43_phy_copy for easier copying between registers, as needed
>> > by LP-PHY init.
>>
>> > + if (bus->sprom.boardflags_hi& B43_BFH_FEM_BT)&&
>> > + (bus->chip_id == 0x5354)&&
>> > + (bus->chip_package == SSB_CHIPPACK_BCM4712S)) {
>> > + b43_phy_set(dev, B43_LPPHY_CRSGAIN_CTL, 0x0006);
>> > + b43_phy_write(dev, B43_LPPHY_GPIO_SELECT, 0x0005);
>> > + b43_phy_write(dev, B43_LPPHY_GPIO_OUTEN, 0xFFFF);
>> > + b43_hf_write(dev, b43_hf_read | 0x0800ULL<< 32);
>> > + }
>>
>> The HF write is wrong. Read the specification:
>> http://bcm-v4.sipsolutions.net/802.11/Mhf
>>
>> Patch otherwise looks ok.
>
> Sorry, I replied to the wrong mail. But this does also apply to V2 patch.
>
> --
> Greetings, Michael.
>
In V2, this line is as follows (b43_hf_read corrected):
b43_hf_write(dev, b43_hf_read(dev) | 0x0800ULL << 32)
The command in the specs is this:
mhf(2, 0x800, 0x800, 1)
2 means B43_SHM_SH_HOSTFHI, 0x800 is the bit to set, and 1 is
allbands, which, per Larry, can be ignored in our current
implementation (it is specific to the caching behavior of the mips
driver).
>From what I read in b43_hf_write, writing to HOSTFHI can be achieved
by left-shifting by 32 (16 for HOSTFMI).
Is the problem that we write all 3 hostflags registers here?
(BTW are there any other known host flags? If there are, maybe we
should #define them.)
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: ar9170usb crashes during iwconfig for ad-hoc mode
From: Christian Lamparter @ 2009-08-03 13:09 UTC (permalink / raw)
To: Joerg Albert; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20090803123642.242160@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
On Monday 03 August 2009 14:36:42 Joerg Albert wrote:
>
> > On Mon, 2009-08-03 at 10:44 +0200, Johannes Berg wrote:
> >
> > > > > ifconfig wlan1 down
> > > > > iwconfig wlan1 mode managed essid huhu
> > > > > ifconfig wlan1 up
> > > > > ifconfig wlan1 down
> > > > > iwconfig wlan1 mode ad-hoc essid huhu_a channel 1
> >
> > > No, it's a bug in cfg80211 :)
> >
> > But it's not making sense to me. I'll have to try to reproduce it. In
> > any case, we shouldn't be calling in to mac80211 from cfg80211 while the
> > interface is down.
>
> I guess this is caused by the call to __cfg80211_leave_ibss()
> in net/wireless/ibss.c::cfg80211_ibss_wext_siwfreq() trying to
> disable the beacon via net/mac80211::ieee80211_ibss_leave().
what about this? (only compiled so far, don't have the device here...)
Regards,
Chr
[-- Attachment #2: bss-beacon.diff --]
[-- Type: text/x-patch, Size: 495 bytes --]
diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
index 099ed3c..9c97ad7 100644
--- a/drivers/net/wireless/ath/ar9170/main.c
+++ b/drivers/net/wireless/ath/ar9170/main.c
@@ -2177,7 +2177,7 @@ static void ar9170_op_bss_info_changed(struct ieee80211_hw *hw,
goto out;
}
- if (changed & (BSS_CHANGED_BEACON | BSS_CHANGED_BEACON_ENABLED)) {
+ if (changed & BSS_CHANGED_BEACON_ENABLED) {
err = ar9170_update_beacon(ar);
if (err)
goto out;
^ permalink raw reply related
* Re: ar9170usb crashes during iwconfig for ad-hoc mode
From: Joerg Albert @ 2009-08-03 12:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1249289274.4561.0.camel@johannes.local>
> On Mon, 2009-08-03 at 10:44 +0200, Johannes Berg wrote:
>
> > > > ifconfig wlan1 down
> > > > iwconfig wlan1 mode managed essid huhu
> > > > ifconfig wlan1 up
> > > > ifconfig wlan1 down
> > > > iwconfig wlan1 mode ad-hoc essid huhu_a channel 1
>
> > No, it's a bug in cfg80211 :)
>
> But it's not making sense to me. I'll have to try to reproduce it. In
> any case, we shouldn't be calling in to mac80211 from cfg80211 while the
> interface is down.
I guess this is caused by the call to __cfg80211_leave_ibss()
in net/wireless/ibss.c::cfg80211_ibss_wext_siwfreq() trying to
disable the beacon via net/mac80211::ieee80211_ibss_leave().
--
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
^ permalink raw reply
* Re: [PATCH RESEND] b43: implement baseband init for LP-PHY <= rev1
From: Michael Buesch @ 2009-08-03 9:15 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: Gábor Stefanik, linux-wireless, Larry Finger
In-Reply-To: <200908031113.38229.mb@bu3sch.de>
On Monday 03 August 2009 11:13:37 Michael Buesch wrote:
> On Monday 03 August 2009 00:18:22 Gábor Stefanik wrote:
> > Implement baseband init for rev.0 and rev.1 LP PHYs. Convert
> > boardflags_hi values to defines.
> > Implement b43_phy_copy for easier copying between registers, as needed
> > by LP-PHY init.
>
> > + if (bus->sprom.boardflags_hi& B43_BFH_FEM_BT)&&
> > + (bus->chip_id == 0x5354)&&
> > + (bus->chip_package == SSB_CHIPPACK_BCM4712S)) {
> > + b43_phy_set(dev, B43_LPPHY_CRSGAIN_CTL, 0x0006);
> > + b43_phy_write(dev, B43_LPPHY_GPIO_SELECT, 0x0005);
> > + b43_phy_write(dev, B43_LPPHY_GPIO_OUTEN, 0xFFFF);
> > + b43_hf_write(dev, b43_hf_read | 0x0800ULL<< 32);
> > + }
>
> The HF write is wrong. Read the specification:
> http://bcm-v4.sipsolutions.net/802.11/Mhf
>
> Patch otherwise looks ok.
Sorry, I replied to the wrong mail. But this does also apply to V2 patch.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH RESEND] b43: implement baseband init for LP-PHY <= rev1
From: Michael Buesch @ 2009-08-03 9:13 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Larry Finger, linux-wireless, Broadcom Wireless
In-Reply-To: <4A7610AE.5000908@gmail.com>
On Monday 03 August 2009 00:18:22 Gábor Stefanik wrote:
> Implement baseband init for rev.0 and rev.1 LP PHYs. Convert
> boardflags_hi values to defines.
> Implement b43_phy_copy for easier copying between registers, as needed
> by LP-PHY init.
> + if (bus->sprom.boardflags_hi& B43_BFH_FEM_BT)&&
> + (bus->chip_id == 0x5354)&&
> + (bus->chip_package == SSB_CHIPPACK_BCM4712S)) {
> + b43_phy_set(dev, B43_LPPHY_CRSGAIN_CTL, 0x0006);
> + b43_phy_write(dev, B43_LPPHY_GPIO_SELECT, 0x0005);
> + b43_phy_write(dev, B43_LPPHY_GPIO_OUTEN, 0xFFFF);
> + b43_hf_write(dev, b43_hf_read | 0x0800ULL<< 32);
> + }
The HF write is wrong. Read the specification:
http://bcm-v4.sipsolutions.net/802.11/Mhf
Patch otherwise looks ok.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH 6/10] drivers/net/wireless/iwlwifi: introduce missing kfree
From: Zhu Yi @ 2009-08-03 9:13 UTC (permalink / raw)
To: Julia Lawall
Cc: Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <Pine.LNX.4.64.0908031109590.8435@pc-004.diku.dk>
On Mon, 2009-08-03 at 17:11 +0800, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> Move orthogonal error handling code up before a kzalloc, so that it
> doesn't have to free the allocated data.
Acked-by: Zhu Yi <yi.zhu@intel.com>
Thanks,
-yi
> The semantic match that finds the problem is as follows:
> (http://www.emn.fr/x-info/coccinelle/)
>
> // <smpl>
> @r exists@
> local idexpression x;
> statement S;
> expression E;
> identifier f,f1,l;
> position p1,p2;
> expression *ptr != NULL;
> @@
>
> x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
> ...
> if (x == NULL) S
> <... when != x
> when != if (...) { <+...x...+> }
> (
> x->f1 = E
> |
> (x->f1 == NULL || ...)
> |
> f(...,x->f1,...)
> )
> ...>
> (
> return \(0\|<+...x...+>\|ptr\);
> |
> return@p2 ...;
> )
>
> @script:python@
> p1 << r.p1;
> p2 << r.p2;
> @@
>
> print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
> ---
> drivers/net/wireless/iwlwifi/iwl-debugfs.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-debugfs.c b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
> index 7707a26..6748a3f 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-debugfs.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
> @@ -310,18 +310,18 @@ static ssize_t iwl_dbgfs_nvm_read(struct file *file,
> return -ENODATA;
> }
>
> + ptr = priv->eeprom;
> + if (!ptr) {
> + IWL_ERR(priv, "Invalid EEPROM/OTP memory\n");
> + return -ENOMEM;
> + }
> +
> /* 4 characters for byte 0xYY */
> buf = kzalloc(buf_size, GFP_KERNEL);
> if (!buf) {
> IWL_ERR(priv, "Can not allocate Buffer\n");
> return -ENOMEM;
> }
> -
> - ptr = priv->eeprom;
> - if (!ptr) {
> - IWL_ERR(priv, "Invalid EEPROM/OTP memory\n");
> - return -ENOMEM;
> - }
> pos += scnprintf(buf + pos, buf_size - pos, "NVM Type: %s\n",
> (priv->nvm_device_type == NVM_DEVICE_TYPE_OTP)
> ? "OTP" : "EEPROM");
^ permalink raw reply
* Re: [PATCH 6/10] drivers/net/wireless/iwlwifi: introduce missing kfree
From: Julia Lawall @ 2009-08-03 9:11 UTC (permalink / raw)
To: Zhu Yi
Cc: Chatre, Reinette, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <1249260246.4069.26.camel@debian>
From: Julia Lawall <julia@diku.dk>
Move orthogonal error handling code up before a kzalloc, so that it
doesn't have to free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
return@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-debugfs.c b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
index 7707a26..6748a3f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-debugfs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-debugfs.c
@@ -310,18 +310,18 @@ static ssize_t iwl_dbgfs_nvm_read(struct file *file,
return -ENODATA;
}
+ ptr = priv->eeprom;
+ if (!ptr) {
+ IWL_ERR(priv, "Invalid EEPROM/OTP memory\n");
+ return -ENOMEM;
+ }
+
/* 4 characters for byte 0xYY */
buf = kzalloc(buf_size, GFP_KERNEL);
if (!buf) {
IWL_ERR(priv, "Can not allocate Buffer\n");
return -ENOMEM;
}
-
- ptr = priv->eeprom;
- if (!ptr) {
- IWL_ERR(priv, "Invalid EEPROM/OTP memory\n");
- return -ENOMEM;
- }
pos += scnprintf(buf + pos, buf_size - pos, "NVM Type: %s\n",
(priv->nvm_device_type == NVM_DEVICE_TYPE_OTP)
? "OTP" : "EEPROM");
^ permalink raw reply related
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