* Virtual STA support
From: Jorge Luis Méndez @ 2009-06-24 16:08 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm looking into support of one physical device to connect to multiple
AP (work as a STA for multiple infrastructure networks). I came across
this Jan'09 post
(http://article.gmane.org/gmane.linux.kernel.wireless.general/27329)
in which it is mentioned that work is being done for ath9k. A few
posts later it is mentioned that for ath5k there was work being done
(http://article.gmane.org/gmane.linux.kernel.wireless.general/27385).
Any updates about this particular feature? Is still being worked on?.
Thank you in advance for any information or pointers provided.
^ permalink raw reply
* Repeater Bridge Mode with ar9170?
From: Jon Loeliger @ 2009-06-24 16:33 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Folks,
I would like to set up a so-called "wireless repeater bridge mode"
using an ar9170 interface and a wired ethernet interface. I see
that there is some support for this mode on the DD-WRT, but I was
wondering if it is supported/available with the ar9170 driver.
If it is not already supported, can anyone point me in the right
direction to help get it implemented?
Thanks,
jdl
^ permalink raw reply
* [PATCH] mac80211: tell SME about real auth state
From: Johannes Berg @ 2009-06-24 20:06 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
When the auth algorithm is rejected, but we don't have
another one to try, we will eventually retry but that
isn't useful -- we'll then do it again and again until
we eventually give up. Instead, we should let the SME
know and go into disabled state. The same applies for
situations where the AP rejects with any other status
code.
Additionally, when trying the next auth algorithm, we
should reset the auth_tries so that just a single lost
frame doesn't lead to us giving up on the third auth
algorithm.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/mlme.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- wireless-testing.orig/net/mac80211/mlme.c 2009-06-24 22:03:04.000000000 +0200
+++ wireless-testing/net/mac80211/mlme.c 2009-06-24 22:03:38.000000000 +0200
@@ -1511,9 +1511,15 @@ static void ieee80211_rx_mgmt_auth(struc
!ieee80211_sta_wep_configured(sdata))
continue;
ifmgd->auth_alg = algs[pos];
- break;
+ ifmgd->auth_tries = 0;
+ return;
}
}
+ /* nothing else to try -- give up */
+ cfg80211_send_rx_auth(sdata->dev, (u8 *) mgmt, len,
+ GFP_KERNEL);
+ ifmgd->state = IEEE80211_STA_MLME_DISABLED;
+ ieee80211_recalc_idle(sdata->local);
return;
}
^ permalink raw reply
* Re: [RFC 00/11] cfg80211 connect API + wireless extension move
From: Luis R. Rodriguez @ 2009-06-24 20:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <20090624120745.239294066@sipsolutions.net>
On Wed, Jun 24, 2009 at 5:07 AM, Johannes Berg<johannes@sipsolutions.net> wrote:
> Maybe we even decide to
> not internalise it this way because orinoco wants to keep
> some ioctls that we'll not offer in cfg80211, not sure yet.
Hm, which ones?
Luis
^ permalink raw reply
* Re: Repeater Bridge Mode with ar9170?
From: Jon Loeliger @ 2009-06-24 22:08 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <1245861185.13356.2.camel@jdl-desktop>
On Wed, 2009-06-24 at 11:33 -0500, Jon Loeliger wrote:
> Folks,
>
> I would like to set up a so-called "wireless repeater bridge mode"
> using an ar9170 interface and a wired ethernet interface. I see
> that there is some support for this mode on the DD-WRT, but I was
> wondering if it is supported/available with the ar9170 driver.
>
> If it is not already supported, can anyone point me in the right
> direction to help get it implemented?
>
> Thanks,
> jdl
OK, so, in the other (non-mac80211) drivers, there was a mode
called IW_MODE_REPEATER that implemented 4-address framing for
clients that provided the bridging ability.
That same functionality is currently not implemented in the
mac80211 code (ie, no NL80211_IFTYPE_REPEATER mode).
My perhaps mistaken understanding of what it would take to
make this work would be to create a new NL80211_IFTYPE_REPEATER
mode that was a hybrid between _STATION and _WDS modes. In
particular, it would act like _STATION as far as association
and authentication are concerned, but would also have _WDS-like
4-address frame handling.
Does that seem about right to you guys? Are folks opposed to
or willing to accept development down those lines? Or has
anyone already done such work and is willing to share?
Thanks,
jdl
^ permalink raw reply
* [PATCH 11/19] drivers/net/wireless: Use PCI_VDEVICE
From: Joe Perches @ 2009-06-25 5:13 UTC (permalink / raw)
To: linux-kernel
Cc: Reinette Chatre, James Ketrenos, Zhu Yi, Luis R. Rodriguez,
ipw2100-devel, linux-wireless, netdev
In-Reply-To: <cover.1245906151.git.joe@perches.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/ipw2x00/ipw2200.c | 10 +++++-----
drivers/net/wireless/prism54/islpci_hotplug.c | 4 +---
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
index 44c29b3..d726b3c 100644
--- a/drivers/net/wireless/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/ipw2x00/ipw2200.c
@@ -11436,11 +11436,11 @@ static struct pci_device_id card_ids[] = {
{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2754, 0, 0, 0},
{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2761, 0, 0, 0},
{PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2762, 0, 0, 0},
- {PCI_VENDOR_ID_INTEL, 0x104f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
- {PCI_VENDOR_ID_INTEL, 0x4220, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, /* BG */
- {PCI_VENDOR_ID_INTEL, 0x4221, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, /* BG */
- {PCI_VENDOR_ID_INTEL, 0x4223, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, /* ABG */
- {PCI_VENDOR_ID_INTEL, 0x4224, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, /* ABG */
+ {PCI_VDEVICE(INTEL, 0x104f), 0},
+ {PCI_VDEVICE(INTEL, 0x4220), 0}, /* BG */
+ {PCI_VDEVICE(INTEL, 0x4221), 0}, /* BG */
+ {PCI_VDEVICE(INTEL, 0x4223), 0}, /* ABG */
+ {PCI_VDEVICE(INTEL, 0x4224), 0}, /* ABG */
/* required last entry */
{0,}
diff --git a/drivers/net/wireless/prism54/islpci_hotplug.c b/drivers/net/wireless/prism54/islpci_hotplug.c
index 3087672..83d3662 100644
--- a/drivers/net/wireless/prism54/islpci_hotplug.c
+++ b/drivers/net/wireless/prism54/islpci_hotplug.c
@@ -49,9 +49,7 @@ static const struct pci_device_id prism54_id_tbl[] = {
/* 3COM 3CRWE154G72 Wireless LAN adapter */
{
- 0x10b7, 0x6001,
- PCI_ANY_ID, PCI_ANY_ID,
- 0, 0, 0
+ PCI_VDEVICE(3COM, 0x6001), 0
},
/* Intersil PRISM Indigo Wireless LAN adapter */
--
1.6.3.1.10.g659a0.dirty
^ permalink raw reply related
* Re: wireless mini-summit in Berlin -- [mspevack@redhat.com: LinuxTag & FUDCon Berlin 2009]
From: John W. Linville @ 2009-06-25 7:14 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20090621144752.GA14349@redhat.com>
More information:
http://spevack.livejournal.com/84441.html
It seems that the FUDCon events will be in the Marshall Haus.
I have not located this yet myself, but I understand it to be in the
Sommergarten area near Messe Sud in the vicinity of LinuxTag.
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: wireless mini-summit in Berlin -- [mspevack@redhat.com: LinuxTag & FUDCon Berlin 2009]
From: Luis Correia @ 2009-06-25 8:27 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <efe7343f0906250111v4d02a77ci6d474abb63ff2940@mail.gmail.com>
Hi all,
(resent due to HTML mailing list restrictions)
> On Thu, Jun 25, 2009 at 08:14, John W. Linville <linville@tuxdriver.com> wrote:
>>
>> More information:
>>
>> http://spevack.livejournal.com/84441.html
>>
>> It seems that the FUDCon events will be in the Marshall Haus.
>> I have not located this yet myself, but I understand it to be in the
>> Sommergarten area near Messe Sud in the vicinity of LinuxTag.
>>
>> John
>> --
>> John W. Linville Someday the world will need a hero, and you
>> linville@tuxdriver.com might be all we have. Be ready.
>> --
this is the location of the mentioned building, it is the one with a
circular ending :)
http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=kaiserdamm,+berlin+germany&sll=52.525961,13.255348&sspn=0.017859,0.055747&ie=UTF8&ll=52.503448,13.273383&spn=0.00463,0.013937&t=h&z=17
Luis Correia
rt2x00 project admin
^ permalink raw reply
* Re: wireless mini-summit in Berlin -- [mspevack@redhat.com: LinuxTag & FUDCon Berlin 2009]
From: John W. Linville @ 2009-06-25 8:37 UTC (permalink / raw)
To: Luis Correia; +Cc: linux-wireless
In-Reply-To: <efe7343f0906250111v4d02a77ci6d474abb63ff2940@mail.gmail.com>
On Thu, Jun 25, 2009 at 09:11:16AM +0100, Luis Correia wrote:
> Hi all,
>
> On Thu, Jun 25, 2009 at 08:14, John W. Linville <linville@tuxdriver.com>wrote:
>
> > More information:
> >
> > http://spevack.livejournal.com/84441.html
> >
> > It seems that the FUDCon events will be in the Marshall Haus.
> > I have not located this yet myself, but I understand it to be in the
> > Sommergarten area near Messe Sud in the vicinity of LinuxTag.
> this is the location of the mentioned building, it is the one with a
> circular ending :)
>
> http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=kaiserdamm,+berlin+germany&sll=52.525961,13.255348&sspn=0.017859,0.055747&ie=UTF8&ll=52.503448,13.273383&spn=0.00463,0.013937&t=h&z=17
Yes, that is it! :-)
LinuxTag is in building 7 of the Berlin Messe (also marked Messegelande
on my map). There are some signs in the LinuxTag area to direct you
to FUDCon as well.
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 v2 10/10] nf_conntrack: Use rcu_barrier() and fix kmem_cache_create flags
From: Jesper Dangaard Brouer @ 2009-06-25 9:29 UTC (permalink / raw)
To: Patrick McHardy, Christoph Lameter, linux-mm
Cc: David S. Miller, Paul E. McKenney, netdev, linux-kernel,
dougthompson, bluesmoke-devel, axboe, christine.caulfield,
Trond.Myklebust, linux-wireless, johannes, yoshfuji, shemminger,
linux-nfs, bfields, neilb, linux-ext4, tytso, adilger,
netfilter-devel
In-Reply-To: <4A423108.60109@trash.net>
On Wed, 2009-06-24 at 15:58 +0200, Patrick McHardy wrote:
> Jesper Dangaard Brouer wrote:
> > Adjusting SLAB_DESTROY_BY_RCU flags.
> >
> > kmem_cache_create("nf_conntrack", ...) does not need the
> > SLAB_DESTROY_BY_RCU flag.
>
> It does need it. We're using it instead of call_rcu() for conntracks.
>
> > But the
> > kmem_cache_create("nf_conntrack_expect", ...) should use the
> > SLAB_DESTROY_BY_RCU flag, because it uses a call_rcu() callback to
> > invoke kmem_cache_free().
>
> No, using call_rcu() means we don't need SLAB_DESTROY_BY_RCU.
> Please see the note in include/linux/slab.h.
Oh, I see. The description is some what cryptic, but I think I got it,
after reading through the code.
BUT this still means that we need to do rcu_barrier() if the
SLAB_DESTROY_BY_RCU is NOT set and we do call_rcu() our self.
Look at: slab.c kmem_cache_destroy()
void kmem_cache_destroy(struct kmem_cache *cachep)
{
...<cut>...
if (__cache_shrink(cachep)) {
slab_error(cachep, "Can't free all objects");
...<cut>...
return;
}
if (unlikely(cachep->flags & SLAB_DESTROY_BY_RCU))
synchronize_rcu();
__kmem_cache_destroy(cachep);
...<cut>...
}
My understanding for the code is (please feel free to correct me): that
if SLAB_DESTROY_BY_RCU _is_ set, then the __cache_shrink() call will
call drain_freelist(), which calls slab_destroy().
If SLAB_DESTROY_BY_RCU _is_ set, then slab_destroy() will then start a
call_rcu() callback to kmem_rcu_free() which calls kmem_cache_free().
Given that the callback code kmem_rcu_free() is not removed, we are not
worried about unloading the module at this point.
I'm a bit worried about what happens if __kmem_cache_destroy() is
invoked and there is still callbacks for kmem_rcu_free() in flight?
The synchronize_rcu() between __cache_shrink() and
__kmem_cache_destroy() should perhaps be changed to rcu_barrier()?
But I'm sure that the SLAB/MM guys will tell me that this case is
handled (and something about its unlinked from the appropiate
lists)??? ;-)
> > RCU barriers, rcu_barrier(), is inserted two places.
> >
> > In nf_conntrack_expect.c nf_conntrack_expect_fini() before the
> > kmem_cache_destroy(), even though the use of the SLAB_DESTROY_BY_RCU
> > flag, because slub does not (currently) handle rcu sync correctly.
>
> I think that should be fixed in slub then.
I don't think so, we/I'm are talking about "nf_conntrack_expect" and not
"nf_conntrack" slab. Clearly the slab "nf_conntrack" is handled
correcly (according to description above).
We still need to make sure the callbacks for "nf_conntrack_expect", are
done before unloading/removing the code they are about to call.
> > And in nf_conntrack_extend.c nf_ct_extend_unregister(), inorder to
> > wait for completion of callbacks to __nf_ct_ext_free_rcu(), which is
> > invoked by __nf_ct_ext_add(). It might be more efficient to call
> > rcu_barrier() in nf_conntrack_core.c nf_conntrack_cleanup_net(), but
> > thats make it more difficult to read the code (as the callback code
> > in located in nf_conntrack_extend.c).
>
> This one looks fine.
Should I make two different patchs?
> > diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> > index 5f72b94..438ce84 100644
> > --- a/net/netfilter/nf_conntrack_core.c
> > +++ b/net/netfilter/nf_conntrack_core.c
> > @@ -1242,7 +1242,7 @@ static int nf_conntrack_init_init_net(void)
> >
> > nf_conntrack_cachep = kmem_cache_create("nf_conntrack",
> > sizeof(struct nf_conn),
> > - 0, SLAB_DESTROY_BY_RCU, NULL);
> > + 0, 0, NULL);
> > if (!nf_conntrack_cachep) {
> > printk(KERN_ERR "Unable to create nf_conn slab cache\n");
> > ret = -ENOMEM;
> > diff --git a/net/netfilter/nf_conntrack_expect.c b/net/netfilter/nf_conntrack_expect.c
> > index afde8f9..56227c2 100644
> > --- a/net/netfilter/nf_conntrack_expect.c
> > +++ b/net/netfilter/nf_conntrack_expect.c
> > @@ -593,7 +593,7 @@ int nf_conntrack_expect_init(struct net *net)
> > if (net_eq(net, &init_net)) {
> > nf_ct_expect_cachep = kmem_cache_create("nf_conntrack_expect",
> > sizeof(struct nf_conntrack_expect),
> > - 0, 0, NULL);
> > + 0, SLAB_DESTROY_BY_RCU, NULL);
> > if (!nf_ct_expect_cachep)
> > goto err2;
> > }
> > @@ -617,8 +617,15 @@ err1:
> > void nf_conntrack_expect_fini(struct net *net)
> > {
> > exp_proc_remove(net);
> > - if (net_eq(net, &init_net))
> > + if (net_eq(net, &init_net)) {
> > + /* hawk@comx.dk 2009-06-24: The rcu_barrier() can be
> > + * removed once the sl*b allocators has been fixed
> > + * regarding handling the SLAB_DESTROY_BY_RCU flag
> > + * correctly.
> > + */
> > + rcu_barrier(); /* Wait for call_rcu() before destroy */
> > kmem_cache_destroy(nf_ct_expect_cachep);
> > + }
> > nf_ct_free_hashtable(net->ct.expect_hash, net->ct.expect_vmalloc,
> > nf_ct_expect_hsize);
> > }
> > diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c
> > index 4b2c769..fef95be 100644
> > --- a/net/netfilter/nf_conntrack_extend.c
> > +++ b/net/netfilter/nf_conntrack_extend.c
> > @@ -186,6 +186,6 @@ void nf_ct_extend_unregister(struct nf_ct_ext_type *type)
> > rcu_assign_pointer(nf_ct_ext_types[type->id], NULL);
> > update_alloc_size(type);
> > mutex_unlock(&nf_ct_ext_type_mutex);
> > - synchronize_rcu();
> > + rcu_barrier(); /* Wait for completion of call_rcu()'s */
> > }
> > EXPORT_SYMBOL_GPL(nf_ct_extend_unregister);
> >
>
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network developer
Cand. Scient Datalog / MSc.
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [LTP] Support of WIFI and W-LAN test cases in LTP
From: Subrata Modak @ 2009-06-25 9:10 UTC (permalink / raw)
To: Georgy Berdyshev
Cc: Luis R. Rodriguez, ltp-list, Luis Carlos Cobo, Jouni Malinen,
linux-wireless@vger.kernel.org, John W. Linville, rahul Baliyan,
Johannes Berg, Jouni.Malinen
In-Reply-To: <ee8eb53d0906231508ta738039m562dee936319624c@mail.gmail.com>
On Tue, 2009-06-23 at 19:08 -0300, Georgy Berdyshev wrote:
> Hi,
>
> Luis did already mention that the idea is to contribute things back to
> LTP or have LTP use it.
Great to hear that again. I was trying to figure out the status of that
work ? When is it expected to complete, any idea ?
Regards--
Subrata
> In case that there is some work going on, I would like to merge those
> tests also into my project
> and later on extend the work with LTP.
>
> In any case, feel free to contact me.
>
> Regards, Georgy
>
> On Tue, Jun 23, 2009 at 12:31 PM, Luis R.
> Rodriguez<lrodriguez@atheros.com> wrote:
> > On Tue, Jun 23, 2009 at 7:48 AM, Subrata
> > Modak<subrata@linux.vnet.ibm.com> wrote:
> >> On Thu, 2009-03-19 at 12:30 +0530, Subrata Modak wrote:
> >>> On Wed, 2009-03-18 at 12:42 -0700, Luis R. Rodriguez wrote:
> >>> > On Mon, Mar 16, 2009 at 11:55 PM, Subrata Modak
> >>> > <subrata@linux.vnet.ibm.com> wrote:
> >>> > > Hi Rahul,
> >>> > >
> >>> > > On Fri, 2009-03-13 at 22:17 +0530, Subrata Modak wrote:
> >>> > >> Hi,
> >>> > >>
> >>> > >> On Fri, 2009-03-13 at 19:02 +0530, rahul Baliyan wrote:
> >>> > >> > Hi,
> >>> > >> >
> >>> > >> > Pl. confirm if LTP contains the test cases of W-LAN and WI-FI.
> >>> > >>
> >>> > >> Nope. We do not have till now. However, we initiated some discussion
> >>> > >> some 6 months back in the same mailing list regarding Wireless Mesh
> >>> > >> Netwoking tests. Please follow the following thread:
> >>> > >>
> >>> > >> http://marc.info/?t=121969812900007&r=1&w=2&n=4,
> >>> > >>
> >>> > >> There are some tests already avilable. We need somebody to volunteer to
> >>> > >> bring them to some shape so that they can be automated and then
> >>> > >> integrated inside LTP. Would you be ready to do that ?
> >>> > >
> >>> > > Would you like to take up my proposal ?
> >>> >
> >>> > BTW I've stashed a Linux wireless testing entry in the Linux
> >>> > Foundation GSoC, hopefully that can be merged back into LTP.
> >>> >
> >>> > https://www.linuxfoundation.org/en/Google_Summer_of_Code_2009#Automation_of_testing_using_mac80211_hwsim_and_Orbit
> >>>
> >>
> >> Hi,
> >>
> >> Is somebody working on this, and still interested to contribute the same
> >> to LTP ?
> >
> > Yes, the idea is to hopefully contribute it back to LTP. Or have LTP
> > use it. I've added Georgy, the student working on this project.
> >
> > Luis
> >
>
>
>
^ permalink raw reply
* [PATCH v3 10/10] nf_conntrack: Use rcu_barrier()
From: Jesper Dangaard Brouer @ 2009-06-25 10:02 UTC (permalink / raw)
To: Patrick McHardy
Cc: Christoph Lameter, linux-mm, David S. Miller, Paul E. McKenney,
netdev, linux-kernel, dougthompson, bluesmoke-devel, axboe,
christine.caulfield, Trond.Myklebust, linux-wireless, johannes,
yoshfuji, shemminger, linux-nfs, bfields, neilb, linux-ext4,
tytso, adilger, netfilter-devel
In-Reply-To: <1245922153.24921.56.camel@localhost.localdomain>
On Thu, 2009-06-25 at 11:29 +0200, Jesper Dangaard Brouer wrote:
> Should I make two different patchs?
Here is the single patch... Patrick tell me if you want it split up?
[PATCH v3 10/10] nf_conntrack: Use rcu_barrier()
From: Jesper Dangaard Brouer <hawk@comx.dk>
RCU barriers, rcu_barrier(), is inserted two places.
In nf_conntrack_expect.c nf_conntrack_expect_fini() before the
kmem_cache_destroy(). Firstly to make sure the callback to the
nf_ct_expect_free_rcu() code is still around. Secondly because I'm
unsure about the consequence of having in flight
nf_ct_expect_free_rcu/kmem_cache_free() calls while doing a
kmem_cache_destroy() slab destroy.
And in nf_conntrack_extend.c nf_ct_extend_unregister(), inorder to
wait for completion of callbacks to __nf_ct_ext_free_rcu(), which is
invoked by __nf_ct_ext_add(). It might be more efficient to call
rcu_barrier() in nf_conntrack_core.c nf_conntrack_cleanup_net(), but
thats make it more difficult to read the code (as the callback code
in located in nf_conntrack_extend.c).
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
---
net/netfilter/nf_conntrack_expect.c | 4 +++-
net/netfilter/nf_conntrack_extend.c | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_conntrack_expect.c b/net/netfilter/nf_conntrack_expect.c
index afde8f9..2032dfe 100644
--- a/net/netfilter/nf_conntrack_expect.c
+++ b/net/netfilter/nf_conntrack_expect.c
@@ -617,8 +617,10 @@ err1:
void nf_conntrack_expect_fini(struct net *net)
{
exp_proc_remove(net);
- if (net_eq(net, &init_net))
+ if (net_eq(net, &init_net)) {
+ rcu_barrier(); /* Wait for call_rcu() before destroy */
kmem_cache_destroy(nf_ct_expect_cachep);
+ }
nf_ct_free_hashtable(net->ct.expect_hash, net->ct.expect_vmalloc,
nf_ct_expect_hsize);
}
diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c
index 4b2c769..fef95be 100644
--- a/net/netfilter/nf_conntrack_extend.c
+++ b/net/netfilter/nf_conntrack_extend.c
@@ -186,6 +186,6 @@ void nf_ct_extend_unregister(struct nf_ct_ext_type *type)
rcu_assign_pointer(nf_ct_ext_types[type->id], NULL);
update_alloc_size(type);
mutex_unlock(&nf_ct_ext_type_mutex);
- synchronize_rcu();
+ rcu_barrier(); /* Wait for completion of call_rcu()'s */
}
EXPORT_SYMBOL_GPL(nf_ct_extend_unregister);
^ permalink raw reply related
* [PATCH 4/4] iwmc3200wifi: fix NULL pointer dereference in iwm_if_free
From: Zhu Yi @ 2009-06-25 10:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
In-Reply-To: <1245925713-14908-4-git-send-email-yi.zhu@intel.com>
The driver private data is now based on wiphy. So we should not
touch the private data after wiphy_free() is called. The patch
fixes the potential NULL pointer dereference by making the
iwm_wdev_free() the last one on the interface removal path.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/netdev.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/netdev.c b/drivers/net/wireless/iwmc3200wifi/netdev.c
index e94e969..bb71f8a 100644
--- a/drivers/net/wireless/iwmc3200wifi/netdev.c
+++ b/drivers/net/wireless/iwmc3200wifi/netdev.c
@@ -155,11 +155,11 @@ void iwm_if_free(struct iwm_priv *iwm)
if (!iwm_to_ndev(iwm))
return;
- free_netdev(iwm_to_ndev(iwm));
- iwm_wdev_free(iwm);
- iwm_priv_deinit(iwm);
kfree(iwm->umac_profile);
iwm->umac_profile = NULL;
+ free_netdev(iwm_to_ndev(iwm));
+ iwm_priv_deinit(iwm);
+ iwm_wdev_free(iwm);
}
int iwm_if_add(struct iwm_priv *iwm)
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/4] iwmc3200wifi: replace netif_rx with netif_rx_ni
From: Zhu Yi @ 2009-06-25 10:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
In-Reply-To: <1245925713-14908-1-git-send-email-yi.zhu@intel.com>
The patch uses netif_rx_ni() over netif_rx() to post buffers to
upper network code because it is always scheduled in a workqueue.
The problem was first observed from a dynamic ticks warning:
"NOHZ: local_softirq_pending ..."
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/rx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index 55871da..5d2239f 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -1373,7 +1373,7 @@ static void iwm_rx_process_packet(struct iwm_priv *iwm,
ndev->stats.rx_packets++;
ndev->stats.rx_bytes += skb->len;
- if (netif_rx(skb) == NET_RX_DROP) {
+ if (netif_rx_ni(skb) == NET_RX_DROP) {
IWM_ERR(iwm, "Packet dropped\n");
ndev->stats.rx_dropped++;
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/4] iwmc3200wifi: simplify calibration map
From: Zhu Yi @ 2009-06-25 10:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
In-Reply-To: <1245925713-14908-2-git-send-email-yi.zhu@intel.com>
The patch simplifies calibration map by combining the init_calib_map
and periodic_calib_map into one calib_map in struct iwm_conf. Now the
initial calibration map is stored in the lower 16 bits of calib_map
and the periodic calibration map is stored in the higher 16 bits.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/fw.c | 19 +++++++++++--------
drivers/net/wireless/iwmc3200wifi/iwm.h | 3 +--
drivers/net/wireless/iwmc3200wifi/lmac.h | 4 ++++
drivers/net/wireless/iwmc3200wifi/main.c | 6 +-----
4 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/fw.c b/drivers/net/wireless/iwmc3200wifi/fw.c
index ec1a15a..c58f614 100644
--- a/drivers/net/wireless/iwmc3200wifi/fw.c
+++ b/drivers/net/wireless/iwmc3200wifi/fw.c
@@ -275,6 +275,7 @@ static int iwm_load_lmac(struct iwm_priv *iwm, const char *img_name)
*/
int iwm_load_fw(struct iwm_priv *iwm)
{
+ unsigned long init_calib_map, periodic_calib_map;
int ret;
/* We first start downloading the UMAC */
@@ -315,23 +316,25 @@ int iwm_load_fw(struct iwm_priv *iwm)
return ret;
}
+ init_calib_map = iwm->conf.calib_map & IWM_CALIB_MAP_INIT_MSK;
+ periodic_calib_map = IWM_CALIB_MAP_PER_LMAC(iwm->conf.calib_map);
+
#ifdef CONFIG_IWM_B0_HW_SUPPORT
if (iwm->conf.hw_b0) {
- clear_bit(PHY_CALIBRATE_RX_IQ_CMD, &iwm->conf.init_calib_map);
- clear_bit(PHY_CALIBRATE_RX_IQ_CMD,
- &iwm->conf.periodic_calib_map);
+ clear_bit(PHY_CALIBRATE_RX_IQ_CMD, &init_calib_map);
+ clear_bit(PHY_CALIBRATE_RX_IQ_CMD, &periodic_calib_map);
}
#endif
/* Read RX IQ calibration result from EEPROM */
- if (test_bit(PHY_CALIBRATE_RX_IQ_CMD, &iwm->conf.init_calib_map)) {
+ if (test_bit(PHY_CALIBRATE_RX_IQ_CMD, &init_calib_map)) {
iwm_store_rxiq_calib_result(iwm);
set_bit(PHY_CALIBRATE_RX_IQ_CMD, &iwm->calib_done_map);
}
iwm_send_prio_table(iwm);
- iwm_send_init_calib_cfg(iwm, iwm->conf.init_calib_map);
+ iwm_send_init_calib_cfg(iwm, init_calib_map);
- while (iwm->calib_done_map != iwm->conf.init_calib_map) {
+ while (iwm->calib_done_map != init_calib_map) {
ret = iwm_notif_handle(iwm, CALIBRATION_RES_NOTIFICATION,
IWM_SRC_LMAC, WAIT_NOTIF_TIMEOUT);
if (ret) {
@@ -340,7 +343,7 @@ int iwm_load_fw(struct iwm_priv *iwm)
}
IWM_DBG_FW(iwm, DBG, "Got calibration result. calib_done_map: "
"0x%lx, requested calibrations: 0x%lx\n",
- iwm->calib_done_map, iwm->conf.init_calib_map);
+ iwm->calib_done_map, init_calib_map);
}
/* Handle LMAC CALIBRATION_COMPLETE notification */
@@ -378,7 +381,7 @@ int iwm_load_fw(struct iwm_priv *iwm)
iwm_send_prio_table(iwm);
iwm_send_calib_results(iwm);
- iwm_send_periodic_calib_cfg(iwm, iwm->conf.periodic_calib_map);
+ iwm_send_periodic_calib_cfg(iwm, periodic_calib_map);
return 0;
diff --git a/drivers/net/wireless/iwmc3200wifi/iwm.h b/drivers/net/wireless/iwmc3200wifi/iwm.h
index 4da57f7..1bad78f 100644
--- a/drivers/net/wireless/iwmc3200wifi/iwm.h
+++ b/drivers/net/wireless/iwmc3200wifi/iwm.h
@@ -65,8 +65,7 @@
struct iwm_conf {
u32 sdio_ior_timeout;
- unsigned long init_calib_map;
- unsigned long periodic_calib_map;
+ unsigned long calib_map;
bool reset_on_fatal_err;
bool auto_connect;
bool wimax_not_present;
diff --git a/drivers/net/wireless/iwmc3200wifi/lmac.h b/drivers/net/wireless/iwmc3200wifi/lmac.h
index db2e5ee..19213e1 100644
--- a/drivers/net/wireless/iwmc3200wifi/lmac.h
+++ b/drivers/net/wireless/iwmc3200wifi/lmac.h
@@ -396,6 +396,10 @@ enum {
CALIBRATION_CMD_NUM,
};
+#define IWM_CALIB_MAP_INIT_MSK 0xFFFF
+#define IWM_CALIB_MAP_PER_LMAC(m) ((m & 0xFF0000) >> 16)
+#define IWM_CALIB_MAP_PER_UMAC(m) ((m & 0xFF000000) >> 24)
+
struct iwm_lmac_calib_hdr {
u8 opcode;
u8 first_grp;
diff --git a/drivers/net/wireless/iwmc3200wifi/main.c b/drivers/net/wireless/iwmc3200wifi/main.c
index 930056b..4fedb45 100644
--- a/drivers/net/wireless/iwmc3200wifi/main.c
+++ b/drivers/net/wireless/iwmc3200wifi/main.c
@@ -53,11 +53,7 @@
static struct iwm_conf def_iwm_conf = {
.sdio_ior_timeout = 5000,
- .init_calib_map = BIT(PHY_CALIBRATE_DC_CMD) |
- BIT(PHY_CALIBRATE_LO_CMD) |
- BIT(PHY_CALIBRATE_TX_IQ_CMD) |
- BIT(PHY_CALIBRATE_RX_IQ_CMD),
- .periodic_calib_map = BIT(PHY_CALIBRATE_DC_CMD) |
+ .calib_map = BIT(PHY_CALIBRATE_DC_CMD) |
BIT(PHY_CALIBRATE_LO_CMD) |
BIT(PHY_CALIBRATE_TX_IQ_CMD) |
BIT(PHY_CALIBRATE_RX_IQ_CMD) |
--
1.6.0.4
^ permalink raw reply related
* [PATCH 3/4] iwmc3200wifi: remove B0 hardware support
From: Zhu Yi @ 2009-06-25 10:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Zhu Yi
In-Reply-To: <1245925713-14908-3-git-send-email-yi.zhu@intel.com>
The patch removes B0 hardware support. Nobody is using it anyway.
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
---
drivers/net/wireless/iwmc3200wifi/eeprom.c | 4 ----
drivers/net/wireless/iwmc3200wifi/fw.c | 6 ------
drivers/net/wireless/iwmc3200wifi/iwm.h | 5 -----
drivers/net/wireless/iwmc3200wifi/main.c | 7 -------
drivers/net/wireless/iwmc3200wifi/rx.c | 7 -------
5 files changed, 0 insertions(+), 29 deletions(-)
diff --git a/drivers/net/wireless/iwmc3200wifi/eeprom.c b/drivers/net/wireless/iwmc3200wifi/eeprom.c
index 0f34b84..365910f 100644
--- a/drivers/net/wireless/iwmc3200wifi/eeprom.c
+++ b/drivers/net/wireless/iwmc3200wifi/eeprom.c
@@ -156,10 +156,6 @@ int iwm_eeprom_init(struct iwm_priv *iwm)
return -ENOMEM;
for (i = IWM_EEPROM_FIRST; i < IWM_EEPROM_LAST; i++) {
-#ifdef CONFIG_IWM_B0_HW_SUPPORT
- if (iwm->conf.hw_b0 && (i >= IWM_EEPROM_INDIRECT_OFFSET))
- break;
-#endif
ret = iwm_eeprom_read(iwm, i);
if (ret < 0) {
IWM_ERR(iwm, "Couldn't read eeprom entry #%d: %s\n",
diff --git a/drivers/net/wireless/iwmc3200wifi/fw.c b/drivers/net/wireless/iwmc3200wifi/fw.c
index c58f614..0f32cab 100644
--- a/drivers/net/wireless/iwmc3200wifi/fw.c
+++ b/drivers/net/wireless/iwmc3200wifi/fw.c
@@ -319,12 +319,6 @@ int iwm_load_fw(struct iwm_priv *iwm)
init_calib_map = iwm->conf.calib_map & IWM_CALIB_MAP_INIT_MSK;
periodic_calib_map = IWM_CALIB_MAP_PER_LMAC(iwm->conf.calib_map);
-#ifdef CONFIG_IWM_B0_HW_SUPPORT
- if (iwm->conf.hw_b0) {
- clear_bit(PHY_CALIBRATE_RX_IQ_CMD, &init_calib_map);
- clear_bit(PHY_CALIBRATE_RX_IQ_CMD, &periodic_calib_map);
- }
-#endif
/* Read RX IQ calibration result from EEPROM */
if (test_bit(PHY_CALIBRATE_RX_IQ_CMD, &init_calib_map)) {
iwm_store_rxiq_calib_result(iwm);
diff --git a/drivers/net/wireless/iwmc3200wifi/iwm.h b/drivers/net/wireless/iwmc3200wifi/iwm.h
index 1bad78f..79d9d89 100644
--- a/drivers/net/wireless/iwmc3200wifi/iwm.h
+++ b/drivers/net/wireless/iwmc3200wifi/iwm.h
@@ -52,8 +52,6 @@
#define IWM_COPYRIGHT "Copyright(c) 2009 Intel Corporation"
#define IWM_AUTHOR "<ilw@linux.intel.com>"
-#define CONFIG_IWM_B0_HW_SUPPORT 1
-
#define IWM_SRC_LMAC UMAC_HDI_IN_SOURCE_FHRX
#define IWM_SRC_UDMA UMAC_HDI_IN_SOURCE_UDMA
#define IWM_SRC_UMAC UMAC_HDI_IN_SOURCE_FW
@@ -86,9 +84,6 @@ struct iwm_conf {
u8 ibss_channel;
u8 mac_addr[ETH_ALEN];
-#ifdef CONFIG_IWM_B0_HW_SUPPORT
- bool hw_b0;
-#endif
};
enum {
diff --git a/drivers/net/wireless/iwmc3200wifi/main.c b/drivers/net/wireless/iwmc3200wifi/main.c
index 4fedb45..484f110 100644
--- a/drivers/net/wireless/iwmc3200wifi/main.c
+++ b/drivers/net/wireless/iwmc3200wifi/main.c
@@ -515,13 +515,6 @@ static int iwm_channels_init(struct iwm_priv *iwm)
{
int ret;
-#ifdef CONFIG_IWM_B0_HW_SUPPORT
- if (iwm->conf.hw_b0) {
- IWM_INFO(iwm, "Workaround EEPROM channels for B0 hardware\n");
- return 0;
- }
-#endif
-
ret = iwm_send_umac_channel_list(iwm);
if (ret) {
IWM_ERR(iwm, "Send channel list failed\n");
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index 5d2239f..3909477 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -924,13 +924,6 @@ static int iwm_ntf_eeprom_proxy(struct iwm_priv *iwm, u8 *buf,
if ((hdr_offset + hdr_len) > IWM_EEPROM_LEN)
return -EINVAL;
-#ifdef CONFIG_IWM_B0_HW_SUPPORT
- if (hdr_offset == IWM_EEPROM_SKU_CAP_OFF) {
- if (eeprom_proxy->buf[0] == 0xff)
- iwm->conf.hw_b0 = 1;
- }
-#endif
-
switch (hdr_type) {
case IWM_UMAC_CMD_EEPROM_TYPE_READ:
memcpy(iwm->eeprom + hdr_offset, eeprom_proxy->buf, hdr_len);
--
1.6.0.4
^ permalink raw reply related
* rt73usb (rt2x00) crash bug on (big-endian) ARM
From: Gert Boddaert @ 2009-06-25 12:18 UTC (permalink / raw)
To: linux-wireless
Hi,
I tested 3 compat-wireless versions:-
we intend to use compat-wireless-2008-04-08.
For our embedded puposes this is relatively stable (although it contains the
mentioned bug).
Also the stable version compat-wireless-2.6.30 kernel was tested, and the latest
"bleeding edge" compat-wireless-2009-06-25.
The drivers were cross-compiled (after some integration work) with the windriver
toolchain for the big-endian IXP420 (x-scale).
We are using the 2.6.27.18 kernel.
the rt73usb is used in AP mode through hostapd, after some patching in hostapd
(the TX not acked thing).
This works remarkably well, accept for the TX rate bug (low throughput ~800Kb/s
from AP to client),
which can be solved in 2008-04-08 by fixing the rate manually (e.g. iwconfig
wlan0 rate 24M).
I am happy to inform, that in the 2009-06-25 version this particular automatic
rate problem seems solved.
Anyway, the bug I want to post about is presumably somewhere in the RX path of
the rt73usb driver (or related stacked drivers).
When running iperf (iperf -c 192.168.x.y -u -t 10 -i 1 -b 20M -r ) and
increasing the load on the AP-RX-side IXP420 to >12 Mb/s, the system crashes.
We are investigating how to get a decent crash dump from the embedded device,
but that will take some work.
I also tested the same setup on a big-endian powerpc-mac G4 (same 2.6.27.18
kernel), but it doesn't crash there probably because the rt73usb is connected to
a USB 1.0/1.1 port and the througput does not rise above 8-9Mb/s.
To summarize...
Problem 1
The device crashes when the load on its RX side goes higher than ~12Mb/s on all
tested driver versions.
Is this a known big-endian issue or does this also
happen on low-spec'ed i386 processors?
Problem 2,
related to compat-wireless-2009-06-25: I can no longer connect from Windows XP
to our embedded AP when using this driver (alignment or endianess issue),
although this does work perfectly with the other driver versions.
Strange thing is, that when booting my test laptop into (ubuntu) linux,
I CAN connect to the embedded AP with the compat-wireless-2009-06-25 driver.
^ permalink raw reply
* [PATCH] Staging: add rt3090 wireless driver
From: Bartlomiej Zolnierkiewicz @ 2009-06-25 13:40 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, linux-wireless
Hi,
This is the vendor driver for the Ralink RT3090 chipset.
It should be later cleaned and ported to use the existing rt2x00
infrastructure or just replaced by the proper version.
[ Unfortunately since it follows the same design/implementation like
rt{286,287,307}0 drivers (already present in the staging tree)
it is highly unlikely that it will see much love from the wireless
development community.. ]
However since the development of the cleaner/proper version can take
significant time lets give distros (i.e. openSUSE seems to already
have the package with the original vendor driver) and users "something"
to use in the meantime.
I forward ported it to 2.6.31-rc1, ported to the Linux build system
and did some initial cleanups. More fixes/cleanups to come later
(it seems that the driver can be made to share most of its code with
the other Ralink drivers already present in the staging tree).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
Patch is too large to be posted on the list, it is here:
http://www.kernel.org/pub/linux/kernel/people/bart/rt3090.patch.bz2
The original driver package:
http://www.ralinktech.com.tw/data/drivers/2009_0612_RT3090_Linux_STA_V2.1.0.0_DPO.tar.gz
The individual porting steps can be seen in the following git tree:
git://git.kernel.org:/pub/scm/linux/kernel/git/bart/misc.git rt3090
drivers/staging/Kconfig | 2
drivers/staging/Makefile | 1
drivers/staging/rt3090/Kconfig | 5
drivers/staging/rt3090/Makefile | 80
drivers/staging/rt3090/action.h | 66
drivers/staging/rt3090/ap.h | 512 +
drivers/staging/rt3090/ap_apcli.h | 276
drivers/staging/rt3090/ap_autoChSel.h | 79
drivers/staging/rt3090/ap_autoChSel_cmm.h | 66
drivers/staging/rt3090/ap_cfg.h | 118
drivers/staging/rt3090/ap_ids.h | 82
drivers/staging/rt3090/ap_mbss.h | 72
drivers/staging/rt3090/ap_uapsd.h | 636 +
drivers/staging/rt3090/ap_wds.h | 212
drivers/staging/rt3090/chips/rt3090.c | 123
drivers/staging/rt3090/chips/rt30xx.c | 525 +
drivers/staging/rt3090/chips/rt3370.c | 121
drivers/staging/rt3090/chips/rt3390.c | 122
drivers/staging/rt3090/chips/rt33xx.c | 536 +
drivers/staging/rt3090/chlist.h | 130
drivers/staging/rt3090/common/action.c | 1057 +++
drivers/staging/rt3090/common/ba_action.c | 1779 +++++
drivers/staging/rt3090/common/cmm_aes.c | 1560 ++++
drivers/staging/rt3090/common/cmm_asic.c | 2753 ++++++++
drivers/staging/rt3090/common/cmm_cfg.c | 295
drivers/staging/rt3090/common/cmm_data.c | 2763 ++++++++
drivers/staging/rt3090/common/cmm_data_pci.c | 1576 ++++
drivers/staging/rt3090/common/cmm_info.c | 3717 +++++++++++
drivers/staging/rt3090/common/cmm_mac_pci.c | 1757 +++++
drivers/staging/rt3090/common/cmm_profile.c | 2321 +++++++
drivers/staging/rt3090/common/cmm_sanity.c | 1718 +++++
drivers/staging/rt3090/common/cmm_sync.c | 734 ++
drivers/staging/rt3090/common/cmm_tkip.c | 966 ++
drivers/staging/rt3090/common/cmm_wep.c | 500 +
drivers/staging/rt3090/common/cmm_wpa.c | 3149 +++++++++
drivers/staging/rt3090/common/crypt_aes.c | 1007 +++
drivers/staging/rt3090/common/crypt_biginteger.c | 1119 +++
drivers/staging/rt3090/common/crypt_dh.c | 234
drivers/staging/rt3090/common/crypt_hmac.c | 279
drivers/staging/rt3090/common/crypt_md5.c | 353 +
drivers/staging/rt3090/common/crypt_sha2.c | 536 +
drivers/staging/rt3090/common/dfs.c | 481 +
drivers/staging/rt3090/common/ee_efuse.c | 1548 ++++
drivers/staging/rt3090/common/ee_prom.c | 308
drivers/staging/rt3090/common/eeprom.c | 98
drivers/staging/rt3090/common/igmp_snoop.c | 1365 ++++
drivers/staging/rt3090/common/mlme.c | 6550 +++++++++++++++++++
drivers/staging/rt3090/common/mlme_ex.c | 215
drivers/staging/rt3090/common/netif_block.c | 147
drivers/staging/rt3090/common/rt_channel.c | 1287 +++
drivers/staging/rt3090/common/rt_rf.c | 201
drivers/staging/rt3090/common/rtmp_init.c | 3882 +++++++++++
drivers/staging/rt3090/common/rtmp_mcu.c | 560 +
drivers/staging/rt3090/common/rtmp_timer.c | 327
drivers/staging/rt3090/common/spectrum.c | 2221 ++++++
drivers/staging/rt3090/config.mk | 187
drivers/staging/rt3090/crypt_hmac.h | 81
drivers/staging/rt3090/crypt_md5.h | 78
drivers/staging/rt3090/crypt_sha2.h | 107
drivers/staging/rt3090/dfs.h | 137
drivers/staging/rt3090/eeprom.h | 82
drivers/staging/rt3090/firmware.h | 517 +
drivers/staging/rt3090/igmp_snoop.h | 152
drivers/staging/rt3090/ipv6.h | 215
drivers/staging/rt3090/link_list.h | 133
drivers/staging/rt3090/mac_pci.h | 454 +
drivers/staging/rt3090/mlme.h | 1360 ++++
drivers/staging/rt3090/mlme_ex.h | 83
drivers/staging/rt3090/mlme_ex_def.h | 53
drivers/staging/rt3090/netif_block.h | 56
drivers/staging/rt3090/oid.h | 1144 +++
drivers/staging/rt3090/pci_main_dev.c | 1194 +++
drivers/staging/rt3090/rt3090.h | 77
drivers/staging/rt3090/rt30xx.h | 48
drivers/staging/rt3090/rt3370.h | 64
drivers/staging/rt3090/rt3390.h | 77
drivers/staging/rt3090/rt33xx.h | 48
drivers/staging/rt3090/rt_ate.c | 6089 ++++++++++++++++++
drivers/staging/rt3090/rt_ate.h | 314
drivers/staging/rt3090/rt_config.h | 126
drivers/staging/rt3090/rt_linux.c | 1623 ++++
drivers/staging/rt3090/rt_linux.h | 1034 +++
drivers/staging/rt3090/rt_main_dev.c | 897 ++
drivers/staging/rt3090/rt_pci_rbus.c | 989 +++
drivers/staging/rt3090/rt_profile.c | 101
drivers/staging/rt3090/rtmp.h | 6873 ++++++++++++++++++++
drivers/staging/rt3090/rtmp_chip.h | 355 +
drivers/staging/rt3090/rtmp_def.h | 1650 +++++
drivers/staging/rt3090/rtmp_dot11.h | 146
drivers/staging/rt3090/rtmp_iface.h | 81
drivers/staging/rt3090/rtmp_mac.h | 2304 +++++++
drivers/staging/rt3090/rtmp_mcu.h | 55
drivers/staging/rt3090/rtmp_os.h | 93
drivers/staging/rt3090/rtmp_pci.h | 110
drivers/staging/rt3090/rtmp_phy.h | 631 +
drivers/staging/rt3090/rtmp_timer.h | 162
drivers/staging/rt3090/rtmp_type.h | 147
drivers/staging/rt3090/spectrum.h | 234
drivers/staging/rt3090/spectrum_def.h | 257
drivers/staging/rt3090/sta/assoc.c | 1673 +++++
drivers/staging/rt3090/sta/auth.c | 491 +
drivers/staging/rt3090/sta/auth_rsp.c | 151
drivers/staging/rt3090/sta/connect.c | 2759 ++++++++
drivers/staging/rt3090/sta/dls.c | 2207 ++++++
drivers/staging/rt3090/sta/rtmp_ckipmic.c | 579 +
drivers/staging/rt3090/sta/rtmp_data.c | 2661 ++++++++
drivers/staging/rt3090/sta/sanity.c | 382 +
drivers/staging/rt3090/sta/sync.c | 1840 +++++
drivers/staging/rt3090/sta/wpa.c | 396 +
drivers/staging/rt3090/sta_ioctl.c | 7559 +++++++++++++++++++++++
drivers/staging/rt3090/vr_ikans.h | 71
drivers/staging/rt3090/wpa.h | 447 +
112 files changed, 104961 insertions(+)
^ permalink raw reply
* Re: [PATCH v2 10/10] nf_conntrack: Use rcu_barrier() and fix kmem_cache_create flags
From: Patrick McHardy @ 2009-06-25 13:59 UTC (permalink / raw)
To: jdb
Cc: Christoph Lameter, linux-mm, David S. Miller, Paul E. McKenney,
netdev, linux-kernel, dougthompson, bluesmoke-devel, axboe,
christine.caulfield, Trond.Myklebust, linux-wireless, johannes,
yoshfuji, shemminger, linux-nfs, bfields, neilb, linux-ext4,
tytso, adilger, netfilter-devel
In-Reply-To: <1245922153.24921.56.camel@localhost.localdomain>
Jesper Dangaard Brouer wrote:
> On Wed, 2009-06-24 at 15:58 +0200, Patrick McHardy wrote:
>> Jesper Dangaard Brouer wrote:
>>> Adjusting SLAB_DESTROY_BY_RCU flags.
>>>
>>> kmem_cache_create("nf_conntrack", ...) does not need the
>>> SLAB_DESTROY_BY_RCU flag.
>> It does need it. We're using it instead of call_rcu() for conntracks.
>>
>>> But the
>>> kmem_cache_create("nf_conntrack_expect", ...) should use the
>>> SLAB_DESTROY_BY_RCU flag, because it uses a call_rcu() callback to
>>> invoke kmem_cache_free().
>> No, using call_rcu() means we don't need SLAB_DESTROY_BY_RCU.
>> Please see the note in include/linux/slab.h.
>
> Oh, I see. The description is some what cryptic, but I think I got it,
> after reading through the code.
>
> BUT this still means that we need to do rcu_barrier() if the
> SLAB_DESTROY_BY_RCU is NOT set and we do call_rcu() our self.
Correct, in that case its necessary.
> My understanding for the code is (please feel free to correct me): that
> if SLAB_DESTROY_BY_RCU _is_ set, then the __cache_shrink() call will
> call drain_freelist(), which calls slab_destroy().
>
> If SLAB_DESTROY_BY_RCU _is_ set, then slab_destroy() will then start a
> call_rcu() callback to kmem_rcu_free() which calls kmem_cache_free().
> Given that the callback code kmem_rcu_free() is not removed, we are not
> worried about unloading the module at this point.
Yep, thats my understanding as well.
> I'm a bit worried about what happens if __kmem_cache_destroy() is
> invoked and there is still callbacks for kmem_rcu_free() in flight?
> The synchronize_rcu() between __cache_shrink() and
> __kmem_cache_destroy() should perhaps be changed to rcu_barrier()?
>
> But I'm sure that the SLAB/MM guys will tell me that this case is
> handled (and something about its unlinked from the appropiate
> lists)??? ;-)
I'll leave that question to the MM guys :)
>>> RCU barriers, rcu_barrier(), is inserted two places.
>>>
>>> In nf_conntrack_expect.c nf_conntrack_expect_fini() before the
>>> kmem_cache_destroy(), even though the use of the SLAB_DESTROY_BY_RCU
>>> flag, because slub does not (currently) handle rcu sync correctly.
>> I think that should be fixed in slub then.
>
> I don't think so, we/I'm are talking about "nf_conntrack_expect" and not
> "nf_conntrack" slab. Clearly the slab "nf_conntrack" is handled
> correcly (according to description above).
>
> We still need to make sure the callbacks for "nf_conntrack_expect", are
> done before unloading/removing the code they are about to call.
Yes, my response was referring to potential sl*b bugs, but
you're correct, we do need rcu_barrier() for expectations.
>>> And in nf_conntrack_extend.c nf_ct_extend_unregister(), inorder to
>>> wait for completion of callbacks to __nf_ct_ext_free_rcu(), which is
>>> invoked by __nf_ct_ext_add(). It might be more efficient to call
>>> rcu_barrier() in nf_conntrack_core.c nf_conntrack_cleanup_net(), but
>>> thats make it more difficult to read the code (as the callback code
>>> in located in nf_conntrack_extend.c).
>> This one looks fine.
>
> Should I make two different patchs?
Either way is fine.
^ permalink raw reply
* Re: kernel crashes, 2.6.30, rt2x00, ath5k, ieee80211_get_*_rate, automatic rate control
From: Richard Zidlicky @ 2009-06-25 8:36 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, linville
In-Reply-To: <20090623202541.GA3635@hash.localnet>
On Tue, Jun 23, 2009 at 04:25:41PM -0400, Bob Copeland wrote:
>
> The patch should already be on the way to stable, but I'll check on it.
thanks, you certainly have my vote that it should get into 2.6.30.*
On an unrelated note, the ath5k device is in a netbook with an wifi LED and
Fn-F2 hotkey to toggle wlan.
The hotkey works, the LED not. What do I need to make the LED working on the
device?
Also, while the hotkey works how do query the current on/off status of it
in Linux?
Richard
^ permalink raw reply
* Re: [PATCH v3 10/10] nf_conntrack: Use rcu_barrier()
From: Patrick McHardy @ 2009-06-25 14:33 UTC (permalink / raw)
To: jdb
Cc: Christoph Lameter, linux-mm, David S. Miller, Paul E. McKenney,
netdev, linux-kernel, dougthompson, bluesmoke-devel, axboe,
christine.caulfield, Trond.Myklebust, linux-wireless, johannes,
yoshfuji, shemminger, linux-nfs, bfields, neilb, linux-ext4,
tytso, adilger, netfilter-devel
In-Reply-To: <1245924178.24921.61.camel@localhost.localdomain>
Jesper Dangaard Brouer wrote:
> RCU barriers, rcu_barrier(), is inserted two places.
>
> In nf_conntrack_expect.c nf_conntrack_expect_fini() before the
> kmem_cache_destroy(). Firstly to make sure the callback to the
> nf_ct_expect_free_rcu() code is still around. Secondly because I'm
> unsure about the consequence of having in flight
> nf_ct_expect_free_rcu/kmem_cache_free() calls while doing a
> kmem_cache_destroy() slab destroy.
>
> And in nf_conntrack_extend.c nf_ct_extend_unregister(), inorder to
> wait for completion of callbacks to __nf_ct_ext_free_rcu(), which is
> invoked by __nf_ct_ext_add(). It might be more efficient to call
> rcu_barrier() in nf_conntrack_core.c nf_conntrack_cleanup_net(), but
> thats make it more difficult to read the code (as the callback code
> in located in nf_conntrack_extend.c).
Applied, thanks Jesper.
^ permalink raw reply
* Re: Announcing ConnMan.net
From: Pádraig Brady @ 2009-06-25 14:39 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-wireless, netdev, jukka.rissanen
In-Reply-To: <1245775609.15367.129.camel@violet>
Marcel Holtmann wrote:
> Intel and Nokia are pleased to jointly launch the ConnMan project, an
> open source project to accelerate and expand development of Internet
> connection management for Linux Devices. ConnMan will be utilized as a
> technology within Moblin and Maemo. Connman.net is now the place to
> bring developers together who are interested in furthering the
> development of Internet connection management within Linux. Review the
> source code for more information. ConnMan is licensed under GPLv2, and
> provides a daemon for managing Internet connections within Linux
> devices. ConnMan is a fully modular system that can be extended, through
> plugins, to support all kinds of wired or wireless technologies.
> Configuration methods, like DHCP and domain name resolving, are
> implemented using plug-ins as well. The plug-in approach allows for easy
> adaption and modification for various use cases. Nokia and Intel will
> jointly maintain the ConnMan project. We'd like to invite all developers
> to join the connman.net effort and community.
>
> Marcel Holtmann, Intel Open Source Technology Center
> Jukka Rissanen, Nokia Devices, Maemo Software
I was wondering how this related to networkmanager.
Dan Williams just posted some comparisons:
http://blogs.gnome.org/dcbw/2009/06/25/networkmanager-and-connman/
cheers,
Pádraig.
^ permalink raw reply
* Re: [PATCH v2 10/10] nf_conntrack: Use rcu_barrier() and fix kmem_cache_create flags
From: Paul E. McKenney @ 2009-06-25 19:32 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Patrick McHardy, Christoph Lameter, linux-mm, David S. Miller,
netdev, linux-kernel, dougthompson, bluesmoke-devel, axboe,
christine.caulfield, Trond.Myklebust, linux-wireless, johannes,
yoshfuji, shemminger, linux-nfs, bfields, neilb, linux-ext4,
tytso, adilger, netfilter-devel
In-Reply-To: <1245922153.24921.56.camel@localhost.localdomain>
On Thu, Jun 25, 2009 at 11:29:13AM +0200, Jesper Dangaard Brouer wrote:
>
> On Wed, 2009-06-24 at 15:58 +0200, Patrick McHardy wrote:
> > Jesper Dangaard Brouer wrote:
> > > Adjusting SLAB_DESTROY_BY_RCU flags.
> > >
> > > kmem_cache_create("nf_conntrack", ...) does not need the
> > > SLAB_DESTROY_BY_RCU flag.
> >
> > It does need it. We're using it instead of call_rcu() for conntracks.
> >
> > > But the
> > > kmem_cache_create("nf_conntrack_expect", ...) should use the
> > > SLAB_DESTROY_BY_RCU flag, because it uses a call_rcu() callback to
> > > invoke kmem_cache_free().
> >
> > No, using call_rcu() means we don't need SLAB_DESTROY_BY_RCU.
> > Please see the note in include/linux/slab.h.
>
> Oh, I see. The description is some what cryptic, but I think I got it,
> after reading through the code.
>
> BUT this still means that we need to do rcu_barrier() if the
> SLAB_DESTROY_BY_RCU is NOT set and we do call_rcu() our self.
>
> Look at: slab.c kmem_cache_destroy()
>
> void kmem_cache_destroy(struct kmem_cache *cachep)
> {
> ...<cut>...
> if (__cache_shrink(cachep)) {
> slab_error(cachep, "Can't free all objects");
> ...<cut>...
> return;
> }
>
> if (unlikely(cachep->flags & SLAB_DESTROY_BY_RCU))
> synchronize_rcu();
>
> __kmem_cache_destroy(cachep);
> ...<cut>...
> }
>
> My understanding for the code is (please feel free to correct me): that
> if SLAB_DESTROY_BY_RCU _is_ set, then the __cache_shrink() call will
> call drain_freelist(), which calls slab_destroy().
>
> If SLAB_DESTROY_BY_RCU _is_ set, then slab_destroy() will then start a
> call_rcu() callback to kmem_rcu_free() which calls kmem_cache_free().
> Given that the callback code kmem_rcu_free() is not removed, we are not
> worried about unloading the module at this point.
>
> I'm a bit worried about what happens if __kmem_cache_destroy() is
> invoked and there is still callbacks for kmem_rcu_free() in flight?
> The synchronize_rcu() between __cache_shrink() and
> __kmem_cache_destroy() should perhaps be changed to rcu_barrier()?
It looks to me like it should, good catch!!! I sent a proposed patch
to the maintainers.
Thanx, Paul
> But I'm sure that the SLAB/MM guys will tell me that this case is
> handled (and something about its unlinked from the appropiate
> lists)??? ;-)
>
>
> > > RCU barriers, rcu_barrier(), is inserted two places.
> > >
> > > In nf_conntrack_expect.c nf_conntrack_expect_fini() before the
> > > kmem_cache_destroy(), even though the use of the SLAB_DESTROY_BY_RCU
> > > flag, because slub does not (currently) handle rcu sync correctly.
> >
> > I think that should be fixed in slub then.
>
> I don't think so, we/I'm are talking about "nf_conntrack_expect" and not
> "nf_conntrack" slab. Clearly the slab "nf_conntrack" is handled
> correcly (according to description above).
>
> We still need to make sure the callbacks for "nf_conntrack_expect", are
> done before unloading/removing the code they are about to call.
>
>
> > > And in nf_conntrack_extend.c nf_ct_extend_unregister(), inorder to
> > > wait for completion of callbacks to __nf_ct_ext_free_rcu(), which is
> > > invoked by __nf_ct_ext_add(). It might be more efficient to call
> > > rcu_barrier() in nf_conntrack_core.c nf_conntrack_cleanup_net(), but
> > > thats make it more difficult to read the code (as the callback code
> > > in located in nf_conntrack_extend.c).
> >
> > This one looks fine.
>
> Should I make two different patchs?
>
>
> > > diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
> > > index 5f72b94..438ce84 100644
> > > --- a/net/netfilter/nf_conntrack_core.c
> > > +++ b/net/netfilter/nf_conntrack_core.c
> > > @@ -1242,7 +1242,7 @@ static int nf_conntrack_init_init_net(void)
> > >
> > > nf_conntrack_cachep = kmem_cache_create("nf_conntrack",
> > > sizeof(struct nf_conn),
> > > - 0, SLAB_DESTROY_BY_RCU, NULL);
> > > + 0, 0, NULL);
> > > if (!nf_conntrack_cachep) {
> > > printk(KERN_ERR "Unable to create nf_conn slab cache\n");
> > > ret = -ENOMEM;
> > > diff --git a/net/netfilter/nf_conntrack_expect.c b/net/netfilter/nf_conntrack_expect.c
> > > index afde8f9..56227c2 100644
> > > --- a/net/netfilter/nf_conntrack_expect.c
> > > +++ b/net/netfilter/nf_conntrack_expect.c
> > > @@ -593,7 +593,7 @@ int nf_conntrack_expect_init(struct net *net)
> > > if (net_eq(net, &init_net)) {
> > > nf_ct_expect_cachep = kmem_cache_create("nf_conntrack_expect",
> > > sizeof(struct nf_conntrack_expect),
> > > - 0, 0, NULL);
> > > + 0, SLAB_DESTROY_BY_RCU, NULL);
> > > if (!nf_ct_expect_cachep)
> > > goto err2;
> > > }
> > > @@ -617,8 +617,15 @@ err1:
> > > void nf_conntrack_expect_fini(struct net *net)
> > > {
> > > exp_proc_remove(net);
> > > - if (net_eq(net, &init_net))
> > > + if (net_eq(net, &init_net)) {
> > > + /* hawk@comx.dk 2009-06-24: The rcu_barrier() can be
> > > + * removed once the sl*b allocators has been fixed
> > > + * regarding handling the SLAB_DESTROY_BY_RCU flag
> > > + * correctly.
> > > + */
> > > + rcu_barrier(); /* Wait for call_rcu() before destroy */
> > > kmem_cache_destroy(nf_ct_expect_cachep);
> > > + }
> > > nf_ct_free_hashtable(net->ct.expect_hash, net->ct.expect_vmalloc,
> > > nf_ct_expect_hsize);
> > > }
> > > diff --git a/net/netfilter/nf_conntrack_extend.c b/net/netfilter/nf_conntrack_extend.c
> > > index 4b2c769..fef95be 100644
> > > --- a/net/netfilter/nf_conntrack_extend.c
> > > +++ b/net/netfilter/nf_conntrack_extend.c
> > > @@ -186,6 +186,6 @@ void nf_ct_extend_unregister(struct nf_ct_ext_type *type)
> > > rcu_assign_pointer(nf_ct_ext_types[type->id], NULL);
> > > update_alloc_size(type);
> > > mutex_unlock(&nf_ct_ext_type_mutex);
> > > - synchronize_rcu();
> > > + rcu_barrier(); /* Wait for completion of call_rcu()'s */
> > > }
> > > EXPORT_SYMBOL_GPL(nf_ct_extend_unregister);
> > >
> >
> --
> Med venlig hilsen / Best regards
> Jesper Brouer
> ComX Networks A/S
> Linux Network developer
> Cand. Scient Datalog / MSc.
> Author of http://adsl-optimizer.dk
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 11/19] drivers/net/wireless: Use PCI_VDEVICE
From: reinette chatre @ 2009-06-25 20:30 UTC (permalink / raw)
To: Joe Perches
Cc: linux-kernel@vger.kernel.org, James Ketrenos, Zhu, Yi,
Luis R. Rodriguez, ipw2100-devel@lists.sourceforge.net,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <10b896c1a1e1f65a4a342ee5aa3452ab8cb43dfb.1245906152.git.joe@perches.com>
On Wed, 2009-06-24 at 22:13 -0700, Joe Perches wrote:
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/wireless/ipw2x00/ipw2200.c | 10 +++++-----
> drivers/net/wireless/prism54/islpci_hotplug.c | 4 +---
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/ipw2x00/ipw2200.c b/drivers/net/wireless/ipw2x00/ipw2200.c
> index 44c29b3..d726b3c 100644
> --- a/drivers/net/wireless/ipw2x00/ipw2200.c
> +++ b/drivers/net/wireless/ipw2x00/ipw2200.c
> @@ -11436,11 +11436,11 @@ static struct pci_device_id card_ids[] = {
> {PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2754, 0, 0, 0},
> {PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2761, 0, 0, 0},
> {PCI_VENDOR_ID_INTEL, 0x1043, 0x8086, 0x2762, 0, 0, 0},
> - {PCI_VENDOR_ID_INTEL, 0x104f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> - {PCI_VENDOR_ID_INTEL, 0x4220, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, /* BG */
> - {PCI_VENDOR_ID_INTEL, 0x4221, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, /* BG */
> - {PCI_VENDOR_ID_INTEL, 0x4223, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, /* ABG */
> - {PCI_VENDOR_ID_INTEL, 0x4224, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, /* ABG */
> + {PCI_VDEVICE(INTEL, 0x104f), 0},
> + {PCI_VDEVICE(INTEL, 0x4220), 0}, /* BG */
> + {PCI_VDEVICE(INTEL, 0x4221), 0}, /* BG */
> + {PCI_VDEVICE(INTEL, 0x4223), 0}, /* ABG */
> + {PCI_VDEVICE(INTEL, 0x4224), 0}, /* ABG */
>
> /* required last entry */
> {0,}
ack for the ipw2200 parts
Thank you
Reinette
^ permalink raw reply
* rt2x00/rt73usb random memory corruption
From: Richard Zidlicky @ 2009-06-25 20:33 UTC (permalink / raw)
To: linux-wireless
Hi,
tried to pin down the occassional mysterious crashes. The crashes occur in several
different places, but almost allways the culprit is a "CR2: 00000000000d5a0b" which
in my configuration causes an illegal access.
As the kernel mostly survives the boot this gave me the opportunity to look at the
live kernel - interestingly a quick grep of /proc/kcore allways shows exactly one
instance of 000d5a0b. In all cases it looks it did overwrite something else that was
supposed to be at that place and just these 4 bytes were modified.
Looking at the addreses that were modified did not yield any interesting patterns
(like page/struct offsets) that would give me any hint. Seems like in the case I looked
at some module ELF information was overwritten, this was during boot so the address
to this location was quite likely found somewhere on the stack?
So far no luck to provoke a crash at the place where the memory corruption happens.
Any ideas? Given that the destination location is probably picked from the stack
- has anyone experience with trying various stack alignments in kernel code?
Here is 2 examples of memory blocks that get overwritten..
Case 1:
*
6621354520 6978652e 65742e74 00007478 00000000
6621354540 696e692e 65742e74 00007478 00000000
6621354560 646f722e 2e617461 31727473 0000312e
6621354600 736b5f5f 61746d79 70675f62 0000006c
6621354620 636b5f5f 61746372 70675f62 0000006c
6621354640 74636573 736e6f69 00000000 00000000
6621354660 f645bef0 f8178020 00000000 00000000
6621354700 f645b7c0 f8235020 00000000 00000000
6621354720 6978652e 65742e74 00007478 00000000
6621354740 f645bf40 f8178020 00000000 00000000
6621354760 f645bff0 f8178020 00000000 00000000
6621355000 f645b740 f8178020 00000000 00000000
6621355020 00000000 00002c0c 00000786 0006b651
6621355040 ** 000d5a0b ** 61726665 70695f67 00003476 ******
***6621355040 \v Z \r \0 e f r a g _ i p v 4 \0 \0 *******
6621355060 646f722e 2e617461 31727473 0000312e
6621355100 75625f5f 61745f67 00656c62 00000000
6621355120 74636573 736e6f69 00000000 00000000
6621355140 6978652e 65742e74 33007478 00627375
6621355160 696e692e 65742e74 00007478 00000000
6621355200 645f666e 61726665 70695f67 00003476
6621355220 61726170 6574656d 00007372 00000000
6621355240 f645bbd0 f645b180 f8db9bc8 00000000
same with od -c
6621354520 . e x i t . t e x t \0 \0 \0 \0 \0 \0
6621354540 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621354560 . r o d a t a . s t r 1 . 1 \0 \0
6621354600 _ _ k s y m t a b _ g p l \0 \0 \0
6621354620 _ _ k c r c t a b _ g p l \0 \0 \0
6621354640 s e c t i o n s \0 \0 \0 \0 \0 \0 \0 \0
6621354660 360 276 E 366 200 027 370 \0 \0 \0 \0 \0 \0 \0 \0
6621354700 300 267 E 366 P # 370 \0 \0 \0 \0 \0 \0 \0 \0
6621354720 . e x i t . t e x t \0 \0 \0 \0 \0 \0
6621354740 @ 277 E 366 200 027 370 \0 \0 \0 \0 \0 \0 \0 \0
6621354760 360 277 E 366 200 027 370 \0 \0 \0 \0 \0 \0 \0 \0
6621355000 @ 267 E 366 200 027 370 \0 \0 \0 \0 \0 \0 \0 \0
6621355020 \0 \0 \0 \0 \f , \0 \0 206 \a \0 \0 Q 266 006 \0
6621355040 \v Z \r \0 e f r a g _ i p v 4 \0 \0 *******
6621355060 . r o d a t a . s t r 1 . 1 \0 \0
6621355100 _ _ b u g _ t a b l e \0 \0 \0 \0 \0
6621355120 s e c t i o n s \0 \0 \0 \0 \0 \0 \0 \0
6621355140 . e x i t . t e x t \0 3 u s b \0
6621355160 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621355200 n f _ d e f r a g _ i p v 4 \0 \0
6621355220 p a r a m e t e r s \0 \0 \0 \0 \0 \0
6621355240 320 273 E 366 200 261 E 366 310 233 333 370 \0 \0 \0 \0
6621355260 270 207 327 370 270 207 327 370 310 233 333 370 \0 \0 \0 \0
Case 2:
6621133760 f64495f0 f6b08b00 f8f6fbc8 00000000
6621134000 f8ee67b8 f8ee67b8 f8f6fbc8 00000000
6621134020 f8b4d964 f6b08b20 f8f6fbc8 00000000
6621134040 61726170 6574656d 00007372 00000000
6621134060 6978652e 65742e74 33007478 00627375
6621134100 696e692e 65742e74 00007478 00000000
6621134120 646f722e 2e617461 31727473 0000312e
6621134140 f8fe672c f8fe672c f9070740 00000000
6621134160 74636573 736e6f69 00000000 00000000
6621134200 00000000 00002c0c 00000786 0006b651
6621134220 *** 000d5a0b 636f6c6c 78616d5f 00000000 ****
6621134240 f64497c0 f8fc7cb4 f9070740 00000000
6621134260 75625f5f 61745f67 00656c62 00000000
6621134300 6e757278 6265645f 00006775 00000000
6621134320 61657270 636f6c6c 00000000 00000000
6621134340 645f666e 61726665 70695f67 00003476
same with od -c
6621133760 360 225 D 366 \0 213 260 366 310 373 366 370 \0 \0 \0 \0
6621134000 270 g 356 370 270 g 356 370 310 373 366 370 \0 \0 \0 \0
6621134020 d 331 264 370 213 260 366 310 373 366 370 \0 \0 \0 \0
6621134040 p a r a m e t e r s \0 \0 \0 \0 \0 \0
6621134060 . e x i t . t e x t \0 3 u s b \0
6621134100 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621134120 . r o d a t a . s t r 1 . 1 \0 \0
6621134140 , g 376 370 , g 376 370 @ \a \a 371 \0 \0 \0 \0
6621134160 s e c t i o n s \0 \0 \0 \0 \0 \0 \0 \0
6621134200 \0 \0 \0 \0 \f , \0 \0 206 \a \0 \0 Q 266 006 \0
6621134220 \v Z \r \0 l l o c _ m a x \0 \0 \0 \0 ********
6621134240 300 227 D 366 264 | 374 370 @ \a \a 371 \0 \0 \0 \0
6621134260 _ _ b u g _ t a b l e \0 \0 \0 \0 \0
6621134300 x r u n _ d e b u g \0 \0 \0 \0 \0 \0
6621134320 p r e a l l o c \0 \0 \0 \0 \0 \0 \0 \0
6621134340 n f _ d e f r a g _ i p v 4 \0 \0
6621134360 270 322 304 302 354 322 304 302 340 304 302 T 340 304 302
6621134400 . e x i t . t e x t \0 \0 \0 \0 \0 \0
6621134420 p a r a m e t e r s \0 \0 \0 \0 \0 \0
6621134440 . e x i t . t e x t \0 \0 \0 \0 \0 \0
6621134460 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621134500 . s m p _ l o c k s \0 \0 \0 \0 \0 \0
6621134520 s e c t i o n s \0 \0 \0 \0 \0 \0 \0 \0
6621134540 _ _ k s y m t a b _ g p l \0 \0 \0
6621134560 s n d _ h d a _ i n t e l \0 \0 \0
6621134600 _ _ k c r c t a b _ g p l \0 \0 \0
6621134620 n f _ d e f r a g _ i p v 4 \0 \0
6621134640 _ _ k c r c t a b _ g p l \0 \0 \0
6621134660 _ _ k s y m t a b _ g p l \0 \0 \0
*
6621134720 \0 220 D 366 320 224 D 366 t 034 373 370 \0 \0 \0 \0
6621134740 310 O 021 370 310 O 021 370 020 O 264 370 \0 \0 \0 \0
6621134760 r t 2 x 0 0 l i b \0 \0 \0 \0 \0 \0 \0
6621135000 317 \t 367 354 322 005 370 020 O 264 370 \0 \0 \0 \0
6621135020 s n d _ h d a _ i n t e l \0 \0 \0
6621135040 030 367 200 370 020 226 D 366 020 O 264 370 \0 \0 \0 \0
6621135060 r t 2 x 0 0 l i b \0 \0 \0 \0 \0 \0 \0
6621135100 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621135120 . r o d a t a . s t r 1 . 1 \0 \0
6621135140 s n d _ h d a _ i n t e l \0 \0 \0
6621135160 . i n i t . t e x t \0 \0 \0 \0 \0 \0
6621135200 r t 2 x 0 0 l i b \0 \0 \0 \0 \0 \0 \0
*
6621135240 s n d _ h d a _ i n t e l \0 \0 \0
6621135260 T 240 375 370 220 224 D 366 t 034 373 370 \0 \0 \0 \0
6621135300 s e c t i o n s \0 \0 \0 \0 \0 \0 \0 \0
Richard
^ 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;
as well as URLs for NNTP newsgroup(s).