* WARNING: at net/wireless/core.c:613 wdev_cleanup_work+0xb7/0xe0
From: Justin Madru @ 2009-09-15 18:10 UTC (permalink / raw)
To: linux-kernel, johannes, linville
Hi,
Currently testing 2.6.32-rc0. I'm getting the following warning upon every
boot.
Are there any consequences of this warning? What does it mean?
WARNING: at net/wireless/core.c:613 wdev_cleanup_work+0xb7/0xe0
[cfg80211]()
Hardware name: MM061
Modules linked in: cpufreq_stats aes_generic binfmt_misc ipv6 container sbs
sbshc ext3 jbd mbcache snd_hda_codec_idt arc4 ecb cryptomgr crypto_hash
aead pcompress crypto_blkcipher crypto_algapi snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm_oss snd_mixer_oss iwl3945 iwlcore dell_laptop snd_pcm
mac80211 dcdbas ac psmouse button battery evdev ricoh_mmc sdhci_pci sdhci
mmc_core processor rtc_cmos rtc_core rtc_lib snd_page_alloc cfg80211 rfkill
reiserfs sr_mod cdrom sg ata_piix ehci_hcd uhci_hcd usbcore nls_base
thermal fan fuse fbcon font bitblit softcursor i915 fb cfbcopyarea video
backlight output cfbimgblt cfbfillrect intel_agp
Pid: 9, comm: events/0 Not tainted 2.6.32-rc0-git #1
Call Trace:
[<f8c85fc7>] ? wdev_cleanup_work+0xb7/0xe0 [cfg80211]
[<f8c85fc7>] ? wdev_cleanup_work+0xb7/0xe0 [cfg80211]
[<c0142810>] warn_slowpath_common+0x70/0x100
[<f8c85fc7>] ? wdev_cleanup_work+0xb7/0xe0 [cfg80211]
[<c01428b5>] warn_slowpath_null+0x15/0x20
[<f8c85fc7>] wdev_cleanup_work+0xb7/0xe0 [cfg80211]
[<c0157894>] worker_thread+0x114/0x1f0
[<f8c85f10>] ? wdev_cleanup_work+0x0/0xe0 [cfg80211]
[<c015c6c0>] ? autoremove_wake_function+0x0/0x50
[<c0157780>] ? worker_thread+0x0/0x1f0
[<c015c434>] kthread+0x74/0x80
[<c015c3c0>] ? kthread+0x0/0x80
[<c0103fcf>] kernel_thread_helper+0x7/0x18
---[ end trace 90f5bf1285e60504 ]---
git blame shows core.c:613 was last modified by:
commit ad002395fd230528281083f4be71855ed7e35b04
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Tue Aug 18 19:51:57 2009 +0200
cfg80211: fix dangling scan request checking
My patch "cfg80211: fix deadlock" broke the code it
was supposed to fix, the scan request checking. But
it's not trivial to put it back the way it was, since
the original patch had a deadlock.
Now do it in a completely new way: queue the check
off to a work struct, where we can freely lock. But
that has some more complications, like needing to
wait for it to be done before the wiphy/rdev can be
destroyed, so some code is required to handle that.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 0b146bb..3d874c6 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1325,6 +1325,8 @@ struct wireless_dev {
struct mutex mtx;
+ struct work_struct cleanup_work;
+
/* currently used for IBSS and SME - might be rearranged later */
u8 ssid[IEEE80211_MAX_SSID_LEN];
u8 ssid_len;
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 69a185b..c150071 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -430,6 +430,8 @@ struct wiphy *wiphy_new(const struct cfg80211_ops *ops,
int sizeof_priv)
INIT_WORK(&rdev->conn_work, cfg80211_conn_work);
INIT_WORK(&rdev->event_work, cfg80211_event_work);
+ init_waitqueue_head(&rdev->dev_wait);
+
/*
* Initialize wiphy parameters to IEEE 802.11 MIB default values.
* Fragmentation and RTS threshold are disabled by default with the
@@ -574,7 +576,23 @@ void wiphy_unregister(struct wiphy *wiphy)
/* protect the device list */
mutex_lock(&cfg80211_mutex);
+ wait_event(rdev->dev_wait, ({
+ int __count;
+ mutex_lock(&rdev->devlist_mtx);
+ __count = rdev->opencount;
+ mutex_unlock(&rdev->devlist_mtx);
+ __count == 0;}));
+
+ mutex_lock(&rdev->devlist_mtx);
BUG_ON(!list_empty(&rdev->netdev_list));
+ mutex_unlock(&rdev->devlist_mtx);
+
+ /*
+ * First remove the hardware from everywhere, this makes
+ * it impossible to find from userspace.
+ */
+ cfg80211_debugfs_rdev_del(rdev);
+ list_del(&rdev->list);
/*
* Try to grab rdev->mtx. If a command is still in progress,
@@ -582,26 +600,18 @@ void wiphy_unregister(struct wiphy *wiphy)
* down the device already. We wait for this command to complete
* before unlinking the item from the list.
* Note: as codified by the BUG_ON above we cannot get here if
- * a virtual interface is still associated. Hence, we can only
- * get to lock contention here if userspace issues a command
- * that identified the hardware by wiphy index.
+ * a virtual interface is still present. Hence, we can only get
+ * to lock contention here if userspace issues a command that
+ * identified the hardware by wiphy index.
*/
cfg80211_lock_rdev(rdev);
-
- if (WARN_ON(rdev->scan_req)) {
- rdev->scan_req->aborted = true;
- ___cfg80211_scan_done(rdev);
- }
-
+ /* nothing */
cfg80211_unlock_rdev(rdev);
- cfg80211_debugfs_rdev_del(rdev);
-
/* If this device got a regulatory hint tell core its
* free to listen now to a new shiny device regulatory hint */
reg_device_remove(wiphy);
- list_del(&rdev->list);
cfg80211_rdev_list_generation++;
device_del(&rdev->wiphy.dev);
debugfs_remove(rdev->wiphy.debugfsdir);
@@ -640,6 +650,31 @@ void wiphy_rfkill_set_hw_state(struct wiphy *wiphy,
bool blocked)
}
EXPORT_SYMBOL(wiphy_rfkill_set_hw_state);
+static void wdev_cleanup_work(struct work_struct *work)
+{
+ struct wireless_dev *wdev;
+ struct cfg80211_registered_device *rdev;
+
+ wdev = container_of(work, struct wireless_dev, cleanup_work);
+ rdev = wiphy_to_dev(wdev->wiphy);
+
+ cfg80211_lock_rdev(rdev);
+
+ if (WARN_ON(rdev->scan_req && rdev->scan_req->dev == wdev->netdev)) {
+ rdev->scan_req->aborted = true;
+ ___cfg80211_scan_done(rdev);
+ }
+
+ cfg80211_unlock_rdev(rdev);
+
+ mutex_lock(&rdev->devlist_mtx);
+ rdev->opencount--;
+ mutex_unlock(&rdev->devlist_mtx);
+ wake_up(&rdev->dev_wait);
+
+ dev_put(wdev->netdev);
+}
+
static int cfg80211_netdev_notifier_call(struct notifier_block * nb,
unsigned long state,
void *ndev)
@@ -663,6 +698,7 @@ static int cfg80211_netdev_notifier_call(struct
notifier_block * nb,
* are added with nl80211.
*/
mutex_init(&wdev->mtx);
+ INIT_WORK(&wdev->cleanup_work, wdev_cleanup_work);
INIT_LIST_HEAD(&wdev->event_list);
spin_lock_init(&wdev->event_lock);
mutex_lock(&rdev->devlist_mtx);
@@ -717,8 +753,22 @@ static int cfg80211_netdev_notifier_call(struct
notifier_block * nb,
default:
break;
}
+ dev_hold(dev);
+ schedule_work(&wdev->cleanup_work);
break;
case NETDEV_UP:
+ /*
+ * If we have a really quick DOWN/UP succession we may
+ * have this work still pending ... cancel it and see
+ * if it was pending, in which case we need to account
+ * for some of the work it would have done.
+ */
+ if (cancel_work_sync(&wdev->cleanup_work)) {
+ mutex_lock(&rdev->devlist_mtx);
+ rdev->opencount--;
+ mutex_unlock(&rdev->devlist_mtx);
+ dev_put(dev);
+ }
#ifdef CONFIG_WIRELESS_EXT
cfg80211_lock_rdev(rdev);
mutex_lock(&rdev->devlist_mtx);
@@ -734,6 +784,7 @@ static int cfg80211_netdev_notifier_call(struct
notifier_block * nb,
break;
}
wdev_unlock(wdev);
+ rdev->opencount++;
mutex_unlock(&rdev->devlist_mtx);
cfg80211_unlock_rdev(rdev);
#endif
@@ -756,7 +807,6 @@ static int cfg80211_netdev_notifier_call(struct
notifier_block * nb,
sysfs_remove_link(&dev->dev.kobj, "phy80211");
list_del_init(&wdev->list);
rdev->devlist_generation++;
- mutex_destroy(&wdev->mtx);
#ifdef CONFIG_WIRELESS_EXT
kfree(wdev->wext.keys);
#endif
diff --git a/net/wireless/core.h b/net/wireless/core.h
index c603f52..f565432 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -50,6 +50,8 @@ struct cfg80211_registered_device {
struct mutex devlist_mtx;
struct list_head netdev_list;
int devlist_generation;
+ int opencount; /* also protected by devlist_mtx */
+ wait_queue_head_t dev_wait;
/* BSSes/scanning */
spinlock_t bss_lock;
Justin Madru
-----------------------------------------------------------------------------------------------------------------------
Send big files for free. Simple steps. No registration.
Visit now http://www.nawelny.com
^ permalink raw reply related
* Re: [rt2x00] rt2500pci is spamming syslogd since upgrade to 2.6.31
From: Ivo van Doorn @ 2009-09-15 16:13 UTC (permalink / raw)
To: Alejandro Riveira Fernández
Cc: linux-kernel@vger.kernel.org, John W. Linville,
linux-wireless@vger.kernel.org
In-Reply-To: <20090915174233.7db381cd@varda>
Hi,
> Hi; my syslog has many entries like this since the upgrade to 2.6.31
>
> phy0 -> rt2500pci_set_device_state: Error - Device failed to enter state 1 (-16).
>
> Sometimes the driver just start spamming like crazy sometimes is at less rate
> sometimes it does not appear.
>
> I'm running 2.6.31 with a revert [1] config follows. If more info is needed
> just ask
>
> [1] http://bugzilla.kernel.org/show_bug.cgi?id=13362
Try disabling powersaving,
iwconfig wlan0 power off
Ivo
^ permalink raw reply
* Re: alloc skb based on a given data buffer
From: Johannes Berg @ 2009-09-15 15:30 UTC (permalink / raw)
To: Zhu Yi
Cc: David Miller, mel@csn.ul.ie, Chatre, Reinette, elendil@planet.nl,
Larry.Finger@lwfinger.net, linville@tuxdriver.com,
penberg@cs.helsinki.fi, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, akpm@linux-foundation.org,
cl@linux-foundation.org, Krauss, Assaf, Abbas, Mohamed,
netdev@vger.kernel.org
In-Reply-To: <1253006111.7549.61.camel@debian>
[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]
On Tue, 2009-09-15 at 17:15 +0800, Zhu Yi wrote:
> On Tue, 2009-09-15 at 17:09 +0800, David Miller wrote:
> > From: Zhu Yi <yi.zhu@intel.com>
> > Date: Tue, 15 Sep 2009 16:57:29 +0800
> >
> > > Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots
> > > and set nr_frags to 2, right? Is this supported allover the network code
> > > already? At a first glance, I didn't find any frags handling in mac80211
> > > stack.
> >
> > You have to pre-pull the link level protocol headers into the
> > linear area, but that's it.
> >
> > Again, see niu.c for details, it does:
> >
> > static void niu_rx_skb_append(struct sk_buff *skb, struct page *page,
> > u32 offset, u32 size)
> > {
> > int i = skb_shinfo(skb)->nr_frags;
> > skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
> >
> > frag->page = page;
> > frag->page_offset = offset;
> > frag->size = size;
> >
> > skb->len += size;
> > skb->data_len += size;
> > skb->truesize += size;
> >
> > skb_shinfo(skb)->nr_frags = i + 1;
> > }
> >
> > to add pages to SKBs and then at the end it goes:
> >
> > skb_reserve(skb, NET_IP_ALIGN);
> > __pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX));
> >
> > Right before giving the SKB to the networking stack. NIU_RXPULL_MAX
> > should be a value that will be large enough to cover the largest
> > possible link level header.
>
> I see. Thanks for this info. I'll try implementing the same for iwlagn.
Hold, mac80211 can't cope with that at this point for sw crypto and
possibly other things.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC] ar9170usb: add ar9170 usbid
From: Christian Lamparter @ 2009-09-15 13:16 UTC (permalink / raw)
To: Stefan Lippers-Hollmann
Cc: Fabian Lenz, linux-wireless, Stephen.Chen, Luis R. Rodriguez
In-Reply-To: <200909151337.15163.s.L-H@gmx.de>
On Tuesday 15 September 2009 13:37:13 Stefan Lippers-Hollmann wrote:
> On Tuesday 15 September 2009, Christian Lamparter wrote:
> > On Tuesday 15 September 2009 07:52:19 Fabian Lenz wrote:
> > > Here the output of lsusb:
> > >
> > > Bus 002 Device 003: ID 0cf3:1002 Atheros Communications, Inc.
> >
> > they made two revisions (v1 and v2).
> > Do you know which one you've got?
>
> v1 (FCC ID: TE7WN821NV1) at least identifies itself as:
> ID 0cf3:9170 Atheros Communications, Inc. AR9170 802.11n
thanks! so, they sticked with the correct id for v1.
> > > and the product page of the WLAN stick:
> > >
> > > http://www.tp-link.com/products/product_des.asp?id=140
> > >
> > > I added { USB_DEVICE(0x0cf3, 0x1002) } to the usb.c file manually some time
> > > ago and got my stick to work but the connection is somewhat unstable... but
> > > that's another story.
> > what firmware image do you use?
> > the two-stage (ar9170-1.fw & ar9170-2.fw) firmware should work.
> > for one-stage you should use a bleeding edge wireless-testing tree.
>
> On this TL-WN821N v1 the one-stage (as published in binary from by Atheros,
> so far I had problems with my self compiled one) and two-stage firmwares
> work equally well on a vanilla 2.6.31 kernel:
the catch here is that some devices won't work with the
two-stage firmware (e.g: AVM FRITZ!WLAN USB Stick N 2.4 )
That's why the delay.
Regards,
Chr
^ permalink raw reply
* Re: [PATCH3]Add analog switch support
From: John W. Linville @ 2009-09-15 12:57 UTC (permalink / raw)
To: Larry Finger; +Cc: Thomas Ilnseher, Broadcom Wireless, linux-wireless
In-Reply-To: <4AAEA510.5060606@lwfinger.net>
On Mon, Sep 14, 2009 at 03:18:24PM -0500, Larry Finger wrote:
> Thomas Ilnseher wrote:
> > On Mo, 2009-09-14 at 21:43 +0200, Gábor Stefanik wrote:
> >> Always send patches to John Linville, and CC linux-wireless.
> > Ok, the last try ...
> >
> > As I've seen Gàbor's patch, I noticed that my previous patch was
> > bullshit. This patch should work:
> >
> > (see: http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore)
> >
> > Signed-off-by: Thomas Ilnseher <illth@gmx.de>
> >
>
> A few points about patch formatting.
>
> The subject of the submittal message should be of the form "[PATCH]
> component: Description". For this one, something like "[PATCH] b43:
> Add LP PHY analog switch support" would be appropriate. If multiple
> versions are needed, indicate that a previous one is superceded by
> [PATCH V2] ..., etc.
>
> There should be a line containing --- after the last signed-off-by line.
>
> Anything between the beginning of the e-mail and the --- line becomes
> part of the permanent record if the patch is accepted. Usually quoted
> material and words like bullshit are avoided. Not always, but usually.
>
> Between the --- line and the start of the patch, you can place
> instructions to Linville regarding the circumstances of the patch and
> its priority. Such directions are useful to distinguish an improvement
> that should wait for the next merge period from a bug fix that should
> be sent upstream ASAP. In this case, the patch fixes a system crash on
> some platforms and should be applied now.
Above is a good summary. I usually refer people here (which has
mostly the same information):
http://linux.yyz.us/patch-format.html
Hth!
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] b43: Don't abuse wl->current_dev in the led work
From: Larry Finger @ 2009-09-15 13:27 UTC (permalink / raw)
To: Michael Buesch; +Cc: John W. Linville, Broadcom Wireless, linux-wireless
In-Reply-To: <200909151149.22565.mb@bu3sch.de>
Michael Buesch wrote:
> On Tuesday 15 September 2009 00:58:18 Larry Finger wrote:
>> Michael Buesch wrote:
>>> Don't abuse wl->current_dev in the LED work for checking whether we're
>>> going down. Add an explicit variable.
>>> This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
>>> in various other places of the driver.
>>>
>>> Signed-off-by: Michael Buesch <mb@bu3sch.de>
>> This patch does not apply. What other patches should I have beyond the
>> current state of wireless-testing?
>
> All patches that are currently queued up.
I found the ones I needed in my mailboxes.
The patch cured my problem. Thanks and ack.
Larry
^ permalink raw reply
* Re: [RFC] ar9170usb: add ar9170 usbid
From: Stefan Lippers-Hollmann @ 2009-09-15 11:37 UTC (permalink / raw)
To: Christian Lamparter
Cc: Fabian Lenz, linux-wireless, Stephen.Chen, Luis R. Rodriguez
In-Reply-To: <200909151006.26631.chunkeey@googlemail.com>
Hi
On Tuesday 15 September 2009, Christian Lamparter wrote:
> On Tuesday 15 September 2009 07:52:19 Fabian Lenz wrote:
> > Here the output of lsusb:
> >
> > Bus 002 Device 003: ID 0cf3:1002 Atheros Communications, Inc.
>
> they made two revisions (v1 and v2).
> Do you know which one you've got?
v1 (FCC ID: TE7WN821NV1) at least identifies itself as:
ID 0cf3:9170 Atheros Communications, Inc. AR9170 802.11n
> > and the product page of the WLAN stick:
> >
> > http://www.tp-link.com/products/product_des.asp?id=140
> >
> > I added { USB_DEVICE(0x0cf3, 0x1002) } to the usb.c file manually some time
> > ago and got my stick to work but the connection is somewhat unstable... but
> > that's another story.
> what firmware image do you use?
> the two-stage (ar9170-1.fw & ar9170-2.fw) firmware should work.
> for one-stage you should use a bleeding edge wireless-testing tree.
On this TL-WN821N v1 the one-stage (as published in binary from by Atheros,
so far I had problems with my self compiled one) and two-stage firmwares
work equally well on a vanilla 2.6.31 kernel:
usb 1-2: new high speed USB device using ehci_hcd and address 4
usb 1-2: New USB device found, idVendor=0cf3, idProduct=9170
usb 1-2: New USB device strings: Mfr=16, Product=32, SerialNumber=48
usb 1-2: Product: USB2.0 WLAN
usb 1-2: Manufacturer: ATHER
usb 1-2: SerialNumber: 12345
usb 1-2: configuration #1 chosen from 1 choice
usb 1-2: reset high speed USB device using ehci_hcd and address 4
usb 1-2: firmware: requesting ar9170.fw
ath: EEPROM regdomain: 0x809c
ath: EEPROM indicates we should expect a country code
ath: doing EEPROM country->regdmn map search
ath: country maps to regdmn code: 0x52
ath: Country alpha2 being used: CN
ath: Regpair used: 0x52
phy2: Selected rate control algorithm 'minstrel'
cfg80211: Calling CRDA for country: CN
Registered led device: ar9170-phy2::tx
Registered led device: ar9170-phy2::assoc
usb 1-2: Atheros AR9170 is registered as 'phy2'
usbcore: registered new interface driver ar9170usb
udev: renamed network interface wlan2 to wlan3
cfg80211: Current regulatory domain intersected:
(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
Regards
Stefan Lippers-Hollmann
^ permalink raw reply
* Re: [PATCH] b43: Don't abuse wl->current_dev in the led work
From: Michael Buesch @ 2009-09-15 9:49 UTC (permalink / raw)
To: Larry Finger; +Cc: John W. Linville, Broadcom Wireless, linux-wireless
In-Reply-To: <4AAECA8A.1060200@lwfinger.net>
On Tuesday 15 September 2009 00:58:18 Larry Finger wrote:
> Michael Buesch wrote:
> > Don't abuse wl->current_dev in the LED work for checking whether we're
> > going down. Add an explicit variable.
> > This fixes a crash on rmmod dereferencing the wl->current_dev NULL pointer
> > in various other places of the driver.
> >
> > Signed-off-by: Michael Buesch <mb@bu3sch.de>
>
> This patch does not apply. What other patches should I have beyond the
> current state of wireless-testing?
All patches that are currently queued up.
--
Greetings, Michael.
^ permalink raw reply
* Re: alloc skb based on a given data buffer
From: Zhu Yi @ 2009-09-15 9:15 UTC (permalink / raw)
To: David Miller
Cc: mel@csn.ul.ie, Chatre, Reinette, elendil@planet.nl,
Larry.Finger@lwfinger.net, linville@tuxdriver.com,
penberg@cs.helsinki.fi, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, akpm@linux-foundation.org,
cl@linux-foundation.org, Krauss, Assaf, johannes@sipsolutions.net,
Abbas, Mohamed, netdev@vger.kernel.org
In-Reply-To: <20090915.020903.93643290.davem@davemloft.net>
On Tue, 2009-09-15 at 17:09 +0800, David Miller wrote:
> From: Zhu Yi <yi.zhu@intel.com>
> Date: Tue, 15 Sep 2009 16:57:29 +0800
>
> > Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots
> > and set nr_frags to 2, right? Is this supported allover the network code
> > already? At a first glance, I didn't find any frags handling in mac80211
> > stack.
>
> You have to pre-pull the link level protocol headers into the
> linear area, but that's it.
>
> Again, see niu.c for details, it does:
>
> static void niu_rx_skb_append(struct sk_buff *skb, struct page *page,
> u32 offset, u32 size)
> {
> int i = skb_shinfo(skb)->nr_frags;
> skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>
> frag->page = page;
> frag->page_offset = offset;
> frag->size = size;
>
> skb->len += size;
> skb->data_len += size;
> skb->truesize += size;
>
> skb_shinfo(skb)->nr_frags = i + 1;
> }
>
> to add pages to SKBs and then at the end it goes:
>
> skb_reserve(skb, NET_IP_ALIGN);
> __pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX));
>
> Right before giving the SKB to the networking stack. NIU_RXPULL_MAX
> should be a value that will be large enough to cover the largest
> possible link level header.
I see. Thanks for this info. I'll try implementing the same for iwlagn.
Thanks,
-yi
^ permalink raw reply
* Re: alloc skb based on a given data buffer
From: David Miller @ 2009-09-15 9:09 UTC (permalink / raw)
To: yi.zhu
Cc: mel, reinette.chatre, elendil, Larry.Finger, linville, penberg,
linux-kernel, linux-wireless, ipw3945-devel, akpm, cl,
assaf.krauss, johannes, mohamed.abbas, netdev
In-Reply-To: <1253005050.7549.58.camel@debian>
From: Zhu Yi <yi.zhu@intel.com>
Date: Tue, 15 Sep 2009 16:57:29 +0800
> Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots
> and set nr_frags to 2, right? Is this supported allover the network code
> already? At a first glance, I didn't find any frags handling in mac80211
> stack.
You have to pre-pull the link level protocol headers into the
linear area, but that's it.
Again, see niu.c for details, it does:
static void niu_rx_skb_append(struct sk_buff *skb, struct page *page,
u32 offset, u32 size)
{
int i = skb_shinfo(skb)->nr_frags;
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
frag->page = page;
frag->page_offset = offset;
frag->size = size;
skb->len += size;
skb->data_len += size;
skb->truesize += size;
skb_shinfo(skb)->nr_frags = i + 1;
}
to add pages to SKBs and then at the end it goes:
skb_reserve(skb, NET_IP_ALIGN);
__pskb_pull_tail(skb, min(len, NIU_RXPULL_MAX));
Right before giving the SKB to the networking stack. NIU_RXPULL_MAX
should be a value that will be large enough to cover the largest
possible link level header.
^ permalink raw reply
* Re: alloc skb based on a given data buffer
From: Zhu Yi @ 2009-09-15 8:57 UTC (permalink / raw)
To: David Miller
Cc: mel@csn.ul.ie, Chatre, Reinette, elendil@planet.nl,
Larry.Finger@lwfinger.net, linville@tuxdriver.com,
penberg@cs.helsinki.fi, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, akpm@linux-foundation.org,
cl@linux-foundation.org, Krauss, Assaf, johannes@sipsolutions.net,
Abbas, Mohamed, netdev@vger.kernel.org
In-Reply-To: <20090915.013321.07006714.davem@davemloft.net>
On Tue, 2009-09-15 at 16:33 +0800, David Miller wrote:
> From: Zhu Yi <yi.zhu@intel.com>
> Date: Tue, 15 Sep 2009 16:30:20 +0800
>
> > This way, device drivers can allocate the Rx buffers with their own size
> > and alignment requirement. i.e. do an order-1 page allocation directly
> > with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx
> > buffer. After DMA is finished, drivers can use the above function to
> > assemble an skb based on the Rx buffer. It should resolve the problem
> > for requiring an order-2 allocation by alloc_skb() in the first place.
>
> You can create paged RX skbs just like drivers such as niu.c
> and others already do, there is no need for special APIs for
> this.
Thanks. So we can put the 8K buffer into 2 skb_shinfo()->frags[] slots
and set nr_frags to 2, right? Is this supported allover the network code
already? At a first glance, I didn't find any frags handling in mac80211
stack.
Thanks,
-yi
^ permalink raw reply
* Re: [RFC] ar9170usb: add ar9170 usbid
From: Christian Lamparter @ 2009-09-15 8:54 UTC (permalink / raw)
To: Stephen Chen; +Cc: Fabian Lenz, linux-wireless@vger.kernel.org, Luis Rodriguez
In-Reply-To: <618D4DE9D5223A45A46C48063FD64045109947ACC0@TAEXMB-01.global.atheros.com>
On Tuesday 15 September 2009 01:39:40 Stephen Chen wrote:
> Hi Christian,
>
> I could not find this VID/PID in INF file in Windows release.
> This ID combination could be obsolete.
you can get their vendor driver from here:
http://www.tp-link.com/support/download.asp?a=1&m=TL-WN821N
-> Driver Files/XP/arusb_xp.inf
--- snip --- Driver Files/${OS}/arusb_${OS}.inf
%ATHR.DeviceDesc.9170% = ATHRXP9170.ndi, USB\VID_0CF3&PID_1002
ATHR.DeviceDesc.9170 = "TP-LINK TL-WN821N 11N Wireless Adapter"
--- snip ---
Looks like they are trying to hijack Atheros' usbid space
by assigning custom product IDs.
This can confuse the unsuspected user and maybe break some stuff.
I'm not joking, this is an accident waiting to happen!
(see "rt2500usb vs. rt73usb" => http://patchwork.kernel.org/patch/45342/
for how this can go wrong.)
For now, you/[Atheros] should add the PID to your win driver as well
(so it's marked as _used_) and get in touch with TP-Link to come up
with a way for vendors - w/o their own VID - to get custom PIDs.
Regards,
Chr
^ permalink raw reply
* Re: alloc skb based on a given data buffer
From: David Miller @ 2009-09-15 8:33 UTC (permalink / raw)
To: yi.zhu
Cc: mel, reinette.chatre, elendil, Larry.Finger, linville, penberg,
linux-kernel, linux-wireless, ipw3945-devel, akpm, cl,
assaf.krauss, johannes, mohamed.abbas, netdev
In-Reply-To: <1253003420.7549.51.camel@debian>
From: Zhu Yi <yi.zhu@intel.com>
Date: Tue, 15 Sep 2009 16:30:20 +0800
> This way, device drivers can allocate the Rx buffers with their own size
> and alignment requirement. i.e. do an order-1 page allocation directly
> with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx
> buffer. After DMA is finished, drivers can use the above function to
> assemble an skb based on the Rx buffer. It should resolve the problem
> for requiring an order-2 allocation by alloc_skb() in the first place.
You can create paged RX skbs just like drivers such as niu.c
and others already do, there is no need for special APIs for
this.
^ permalink raw reply
* alloc skb based on a given data buffer
From: Zhu Yi @ 2009-09-15 8:30 UTC (permalink / raw)
To: Mel Gorman
Cc: Chatre, Reinette, Frans Pop, Larry Finger, John W. Linville,
Pekka Enberg, linux-kernel@vger.kernel.org,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Andrew Morton,
cl@linux-foundation.org, Krauss, Assaf, Johannes Berg,
Abbas, Mohamed, netdev
In-Reply-To: <20090914130612.GA11778@csn.ul.ie>
[ Cc netdev and change the subject ]
On Mon, 2009-09-14 at 21:06 +0800, Mel Gorman wrote:
> > Essentially, the hardware only requires an order-1 allocation aligned on
> > 256 bytes boundary. But as it is used as an SKB, a trailing struct
> > skb_shared_info is added. This forces us to both increase the order and
> > do alignment ourselves. I believe some improvement could be done here.
> > But it should not be an easy one.
> >
>
> Probably not. I can only assume that moving the location of
> skb_shared_info such that it is sometimes located after the buffer and
> sometimes allocated via a separate kmalloc() would be a significant
> undertaking.
Shall I propose below function as a variant to alloc_skb()?
struct sk_buff *alloc_skb_attach_buff(void *data_buff,
unsigned int real_size,
unsigned int size, gfp_t mask);
If real_size >= size + sizeof(struct skb_shared_info), we can still put
the shinfo at the end of the buffer. Otherwise we can allocate from a
new slab that put sk_buff and shinfo together. Of course, kfree_skbmem()
needs to recognize it.
This way, device drivers can allocate the Rx buffers with their own size
and alignment requirement. i.e. do an order-1 page allocation directly
with free_pages() in the iwlagn driver for a 256 bytes aligned 8K Rx
buffer. After DMA is finished, drivers can use the above function to
assemble an skb based on the Rx buffer. It should resolve the problem
for requiring an order-2 allocation by alloc_skb() in the first place.
Comments are welcome.
Thanks,
-yi
^ permalink raw reply
* Re: [RFC] ar9170usb: add ar9170 usbid
From: Christian Lamparter @ 2009-09-15 8:06 UTC (permalink / raw)
To: Fabian Lenz; +Cc: linux-wireless, Stephen.Chen, Luis R. Rodriguez
In-Reply-To: <200909150752.19146.lenz_fabian@yahoo.de>
On Tuesday 15 September 2009 07:52:19 Fabian Lenz wrote:
> Here the output of lsusb:
>
> Bus 002 Device 003: ID 0cf3:1002 Atheros Communications, Inc.
they made two revisions (v1 and v2).
Do you know which one you've got?
> and the product page of the WLAN stick:
>
> http://www.tp-link.com/products/product_des.asp?id=140
>
> I added { USB_DEVICE(0x0cf3, 0x1002) } to the usb.c file manually some time
> ago and got my stick to work but the connection is somewhat unstable... but
> that's another story.
what firmware image do you use?
the two-stage (ar9170-1.fw & ar9170-2.fw) firmware should work.
for one-stage you should use a bleeding edge wireless-testing tree.
Regards,
Chr
^ permalink raw reply
* Re: [PATCH] cfg80211: don't report SME connection errs at SIOCSIW{FREQ/AP/ESSID}
From: Holger Schurig @ 2009-09-15 6:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John W Linville
In-Reply-To: <1252950234.23427.51.camel@johannes.local>
> And doesn't look correct to me at all. probably something
> missing wrt. disconnect() while connecting.
Can you then outline the right solution ?
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: RTL8187B wireless driver issue
From: Hin-Tak Leung @ 2009-09-15 4:04 UTC (permalink / raw)
To: Vignette consultant; +Cc: Larry Finger, linux-wireless
In-Reply-To: <3b0e19890909141951uf8b80c0ta3619045b54efff3@mail.gmail.com>
On Tue, Sep 15, 2009 at 3:51 AM, Vignette consultant
<vignette75@gmail.com> wrote:
> 1 how can i check if wpa_supplicant is running or not?
(sigh...) well, have a look at 'ps -lax' , e.g.
ps -lax | grep wpa
ps -lax | grep -i net
ps -lax | grep dh
and see if there is anything you don't know the nature of... (and look
it up on the web!).
> 3 are you saying "to use different driver"?
yes, different version/release of the driver
>
> 2 where do i need put essid, so udev can use it?
YMMV, on my system (fedora) these are the system locations for wlan2.
/etc/wpa_supplicant/wpa_supplicant.conf
/etc/sysconfig/networking/devices/ifcfg-wlan2
/etc/sysconfig/networking/devices/keys-wlan2
/etc/sysconfig/networking/profiles/default/ifcfg-wlan2
/etc/sysconfig/networking/profiles/default/keys-wlan2
essid is in /etc/wpa_supplicant/wpa_supplicant.conf and ifcfg-*, and
the key is in keys-* and also in
/etc/wpa_supplicant/wpa_supplicant.conf . Also if you use
NetworkManager, it can take credentials from the gnome-keyring-manager
as well.
In the normal course of event, when one if up a network interface,
udev tells either the network service to configure the interface or
talk to NetworkManger via dbus to do it. both network service and
NetworkManager tells wpa_supplicant to start scanning for known APs or
open APs and try to authenticate.
If you are not aware of what wpa_supplicant might be doing, it could
unset whatever credentials you try to set as it scans and look for
known or open APs. You should try to use the NetworkManager applet or
Wireless assistant to set essid and credentials, rather than by hand
on the command line.
Hmm, your Vista screenshot says the AP is unsecure (and the signal
strength is poor), is that the case?
^ permalink raw reply
* Re: RTL8187B wireless driver issue
From: Vignette consultant @ 2009-09-15 2:51 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Larry Finger, linux-wireless
In-Reply-To: <3ace41890909141824i2f274a91rc19e50eac254e950@mail.gmail.com>
1 how can i check if wpa_supplicant is running or not?
3 are you saying "to use different driver"?
2 where do i need put essid, so udev can use it?
On 9/14/09, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
> On Mon, Sep 14, 2009 at 10:34 PM, Vignette consultant
> <vignette75@gmail.com> wrote:
>> Hi
>>
>> I get timed out errors consistently as per attached log file.
>> I tried several Live Cds from fedora, sidux - but i get the same dhcp
>> error. I used to be able to connect before.
>>
>> Please check attached log and see if you can point me towards the
>> solution.
>
> Your log do not add anything new - I already asked you to do 3 things,
> and there is no indication you have done any of them; there is no
> point writing me the same things you had wrote to Larry or
> linux-wireless, and try to get a private answer - Your won't. (please
> do not remove the CC:'s and please do not write privately on general
> help matters).
>
> 1) make sure that wpa_supplicant is *not* running - newer liveCDs can
> have wpa_supplicant working (compare to older which does not use it).
>
> 2) make sure your authentication credentials - essid, passphases - are
> in the network config files and agree with what you are trying to set
> on the command line, just in case udev wants to unset your credentials
> you are setting manually on the comamnd line.
>
> 3) switch from kernel-modules-backport to a different version of
> compat-wireless and/or vice versa. There were some transient bugs a
> while ago.
>
>>
>> thanks
>> sam
>>
>> On 9/14/09, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>>> On Mon, Sep 14, 2009 at 6:56 PM, Vignette consultant
>>> <vignette75@gmail.com> wrote:
>>>> Larry,
>>>>
>>>> I got the same error even after adding wlan0 in
>>>> /etc/network/interfaces file. I set the essid using "sudo iwconfig
>>>> wlan0 essid linksys" command and restarted network. I tried other
>>>> essids, but it gives same error.
>>>>
>>>> Attached files contain log files. Please advise about solution.
>>>>
>>>> How do I disable usb monitoring log, so I can see wlan0 interface log
>>>> from dmesg?
>>>>
>>>> Thanks
>>>> Sam
>>>>
>>>> On 9/14/09, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>>> Vignette consultant wrote:
>>>>>> Hi
>>>>>>
>>>>>> Attached files contain several logs of various commands. The log-1
>>>>>> file is before running command and log-2 file is after running
>>>>>> specific command.
>>>>>>
>>>>>> Here are commands that I give as soon as I log in. It's server
>>>>>> edition.
>>>>>>
>>>>>> $ sudo ifconfig wlan0 up
>>>>>> $ sudo iwconfig wlan0 ESSID linksys
>>>>>> $ sudo dhclient wlan0 - results in no IP addr leased
>>>>>
>>>>> Your wireless has not associated and has no communication, which is
>>>>> why it cannot get an IP using DHCP.
>>>>>
>>>>> A quick check with Google indicates that Ubuntu uses
>>>>> /etc/network/interfaces to control the devices. Once that is correct,
>>>>> you should be able to 'sudo /etc/init.d/networking restart' to start
>>>>> the network. If the server is properly configured, the network should
>>>>> start on boot.
>>>>>
>>>>> BTW, the dmesg buffer is circular. All that usb monitoring output has
>>>>> completely filled the buffer, and it contains no useful information.
>>>>>
>>>>
>>>
>>> scanning works, so there doesn't seem to be anything wrong with the
>>> device or the driver itself. However, even for static configuration,
>>> sometimes wpa_supplicant can still be involved and interfere, so you
>>> probably want to make sure you put all the relevant config in
>>> wpa_supplicant.conf , as well as manually; or make sure no other
>>> network tools are running. (udev can launch wpa_supplicant/dhcp on
>>> ifconfig up automatically - the 'not ready' messages are from udev
>>> hooks). Lastly, I think the Ubuntu/Debian family packages
>>> compat-wireless as 'kernel-modules-backport' or something; try that or
>>> even compat-wireless. ( a while back there was a bug with
>>> associattion).
>>>
>>
>
^ permalink raw reply
* email for compat-wireless patch contact...
From: Hin-Tak Leung @ 2009-09-15 2:32 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
Hi Luis,
The e-mail addressed listed for you (the winlab one) on
http://linuxwireless.org/en/users/Download and the README inside
compat-wireless bounced... time to update with either the gmail or the
atheros address?
Cheers,
Hin-Tak
^ permalink raw reply
* [PATCH] compat-2.6: adding driver-select script support for rtl818x
From: Hin-Tak Leung @ 2009-09-15 2:26 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Hin-Tak Leung, Hin-Tak Leung
adding driver-select script support for rtl818x
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
scripts/driver-select | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/scripts/driver-select b/scripts/driver-select
index e0d7305..dcb777c 100755
--- a/scripts/driver-select
+++ b/scripts/driver-select
@@ -44,6 +44,7 @@ function usage {
echo -e "\t${CYAN}ath${NORMAL} < ${PURPLE} ath5k ath9k ar9170 ${NORMAL}>"
echo -e "\t${CYAN}intel${NORMAL} < ${PURPLE} iwl3945 iwlagn ipw2100 ipw2200 ${NORMAL}>"
echo -e "\t${CYAN}iwlwifi${NORMAL} < ${PURPLE} iwl3945 iwlagn ${NORMAL}>"
+ echo -e "\t${CYAN}rtl818x${NORMAL} < ${PURPLE} rtl8180 rtl8187 ${NORMAL}>"
echo -e "\t${CYAN}wl12xx${NORMAL} < ${PURPLE} wl1251 (SPI and SDIO) wl1271 ${NORMAL}>"
echo -e "Restoring compat-wireless:"
@@ -127,6 +128,13 @@ function disable_var_01 {
disable_var
}
+function disable_var_02 {
+ #var_01 with eeprom not disabled
+ disable_lib80211
+ disable_ssb
+ disable_usbnet
+}
+
function select_ath_driver
{
backup_file $ATH_MAKEFILE
@@ -227,6 +235,10 @@ case $1 in
select_driver CONFIG_ATH_COMMON
select_ath_driver CONFIG_AR9170_USB
;;
+ rtl818x)
+ select_drivers CONFIG_RTL8180 CONFIG_RTL8187
+ disable_var_02
+ ;;
zd1211rw)
select_driver CONFIG_ZD1211RW
disable_var_01
--
1.6.2.5
^ permalink raw reply related
* [PATCH] compat-2.6: adding notes on installing to non-running kernel
From: Hin-Tak Leung @ 2009-09-15 2:26 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Hin-Tak Leung, Hin-Tak Leung
adding notes on installing to non-running kernel
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
README | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 7c6c2cd..380fc5a 100644
--- a/README
+++ b/README
@@ -142,6 +142,15 @@ compat-wireless-2.6 drivers for it you can use this syntax:
make KLIB=/home/mcgrof/kernels/linux-2.6.23.9 KLIB_BUILD=/home/mcgrof/kernels/linux-2.6.23.9
+If you have a kernel installed, which is not your currently running kernel (e.g. via
+distro updates; plus its corresponding kernel-dev package), you can use this syntax:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64
+
+ and to install to your system's root path for the non-running kernel:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64 KMODPATH_ARG='INSTALL_MOD_PATH=' install
+
Bugs
-----
--
1.6.2.5
^ permalink raw reply related
* [PATCH] compat-2.6: adding notes on installing to non-running kernel
From: Hin-Tak Leung @ 2009-09-15 2:20 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Hin-Tak Leung, Hin-Tak Leung
adding notes on installing to non-running kernel
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
README | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 7c6c2cd..380fc5a 100644
--- a/README
+++ b/README
@@ -142,6 +142,15 @@ compat-wireless-2.6 drivers for it you can use this syntax:
make KLIB=/home/mcgrof/kernels/linux-2.6.23.9 KLIB_BUILD=/home/mcgrof/kernels/linux-2.6.23.9
+If you have a kernel installed, which is not your currently running kernel (e.g. via
+distro updates; plus its corresponding kernel-dev package), you can use this syntax:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64
+
+ and to install to your system's root path for the non-running kernel:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64 KMODPATH_ARG='INSTALL_MOD_PATH=' install
+
Bugs
-----
--
1.6.2.5
^ permalink raw reply related
* [PATCH] adding notes on installing to non-running kernel
From: Hin-Tak Leung @ 2009-09-15 2:17 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Hin-Tak Leung, Hin-Tak Leung
adding notes on installing to non-running kernel
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
README | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/README b/README
index 7c6c2cd..380fc5a 100644
--- a/README
+++ b/README
@@ -142,6 +142,15 @@ compat-wireless-2.6 drivers for it you can use this syntax:
make KLIB=/home/mcgrof/kernels/linux-2.6.23.9 KLIB_BUILD=/home/mcgrof/kernels/linux-2.6.23.9
+If you have a kernel installed, which is not your currently running kernel (e.g. via
+distro updates; plus its corresponding kernel-dev package), you can use this syntax:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64
+
+ and to install to your system's root path for the non-running kernel:
+
+make KLIB=/lib/modules/2.6.30.6-53.fc11.x86_64 KMODPATH_ARG='INSTALL_MOD_PATH=' install
+
Bugs
-----
--
1.6.2.5
^ permalink raw reply related
* [PATCH] compat-2.6: adding driver-select script support for rtl818x
From: Hin-Tak Leung @ 2009-09-15 2:16 UTC (permalink / raw)
To: linux-wireless, mcgrof; +Cc: Hin-Tak Leung, Hin-Tak Leung
adding driver-select script support for rtl818x
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
---
scripts/driver-select | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/scripts/driver-select b/scripts/driver-select
index e0d7305..dcb777c 100755
--- a/scripts/driver-select
+++ b/scripts/driver-select
@@ -44,6 +44,7 @@ function usage {
echo -e "\t${CYAN}ath${NORMAL} < ${PURPLE} ath5k ath9k ar9170 ${NORMAL}>"
echo -e "\t${CYAN}intel${NORMAL} < ${PURPLE} iwl3945 iwlagn ipw2100 ipw2200 ${NORMAL}>"
echo -e "\t${CYAN}iwlwifi${NORMAL} < ${PURPLE} iwl3945 iwlagn ${NORMAL}>"
+ echo -e "\t${CYAN}rtl818x${NORMAL} < ${PURPLE} rtl8180 rtl8187 ${NORMAL}>"
echo -e "\t${CYAN}wl12xx${NORMAL} < ${PURPLE} wl1251 (SPI and SDIO) wl1271 ${NORMAL}>"
echo -e "Restoring compat-wireless:"
@@ -127,6 +128,13 @@ function disable_var_01 {
disable_var
}
+function disable_var_02 {
+ #var_01 with eeprom not disabled
+ disable_lib80211
+ disable_ssb
+ disable_usbnet
+}
+
function select_ath_driver
{
backup_file $ATH_MAKEFILE
@@ -227,6 +235,10 @@ case $1 in
select_driver CONFIG_ATH_COMMON
select_ath_driver CONFIG_AR9170_USB
;;
+ rtl818x)
+ select_drivers CONFIG_RTL8180 CONFIG_RTL8187
+ disable_var_02
+ ;;
zd1211rw)
select_driver CONFIG_ZD1211RW
disable_var_01
--
1.6.2.5
^ permalink raw reply related
* Re: RTL8187B wireless driver issue
From: Hin-Tak Leung @ 2009-09-15 1:24 UTC (permalink / raw)
To: Vignette consultant; +Cc: Larry Finger, linux-wireless
In-Reply-To: <3b0e19890909141434t758a9b3dk2799623dfb19c6a6@mail.gmail.com>
On Mon, Sep 14, 2009 at 10:34 PM, Vignette consultant
<vignette75@gmail.com> wrote:
> Hi
>
> I get timed out errors consistently as per attached log file.
> I tried several Live Cds from fedora, sidux - but i get the same dhcp
> error. I used to be able to connect before.
>
> Please check attached log and see if you can point me towards the solution.
Your log do not add anything new - I already asked you to do 3 things,
and there is no indication you have done any of them; there is no
point writing me the same things you had wrote to Larry or
linux-wireless, and try to get a private answer - Your won't. (please
do not remove the CC:'s and please do not write privately on general
help matters).
1) make sure that wpa_supplicant is *not* running - newer liveCDs can
have wpa_supplicant working (compare to older which does not use it).
2) make sure your authentication credentials - essid, passphases - are
in the network config files and agree with what you are trying to set
on the command line, just in case udev wants to unset your credentials
you are setting manually on the comamnd line.
3) switch from kernel-modules-backport to a different version of
compat-wireless and/or vice versa. There were some transient bugs a
while ago.
>
> thanks
> sam
>
> On 9/14/09, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>> On Mon, Sep 14, 2009 at 6:56 PM, Vignette consultant
>> <vignette75@gmail.com> wrote:
>>> Larry,
>>>
>>> I got the same error even after adding wlan0 in
>>> /etc/network/interfaces file. I set the essid using "sudo iwconfig
>>> wlan0 essid linksys" command and restarted network. I tried other
>>> essids, but it gives same error.
>>>
>>> Attached files contain log files. Please advise about solution.
>>>
>>> How do I disable usb monitoring log, so I can see wlan0 interface log
>>> from dmesg?
>>>
>>> Thanks
>>> Sam
>>>
>>> On 9/14/09, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>> Vignette consultant wrote:
>>>>> Hi
>>>>>
>>>>> Attached files contain several logs of various commands. The log-1
>>>>> file is before running command and log-2 file is after running
>>>>> specific command.
>>>>>
>>>>> Here are commands that I give as soon as I log in. It's server
>>>>> edition.
>>>>>
>>>>> $ sudo ifconfig wlan0 up
>>>>> $ sudo iwconfig wlan0 ESSID linksys
>>>>> $ sudo dhclient wlan0 - results in no IP addr leased
>>>>
>>>> Your wireless has not associated and has no communication, which is
>>>> why it cannot get an IP using DHCP.
>>>>
>>>> A quick check with Google indicates that Ubuntu uses
>>>> /etc/network/interfaces to control the devices. Once that is correct,
>>>> you should be able to 'sudo /etc/init.d/networking restart' to start
>>>> the network. If the server is properly configured, the network should
>>>> start on boot.
>>>>
>>>> BTW, the dmesg buffer is circular. All that usb monitoring output has
>>>> completely filled the buffer, and it contains no useful information.
>>>>
>>>
>>
>> scanning works, so there doesn't seem to be anything wrong with the
>> device or the driver itself. However, even for static configuration,
>> sometimes wpa_supplicant can still be involved and interfere, so you
>> probably want to make sure you put all the relevant config in
>> wpa_supplicant.conf , as well as manually; or make sure no other
>> network tools are running. (udev can launch wpa_supplicant/dhcp on
>> ifconfig up automatically - the 'not ready' messages are from udev
>> hooks). Lastly, I think the Ubuntu/Debian family packages
>> compat-wireless as 'kernel-modules-backport' or something; try that or
>> even compat-wireless. ( a while back there was a bug with
>> associattion).
>>
>
^ 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