* Re: Disabling "TCP Treason uncloaked"
From: David S. Miller @ 2006-05-03 6:32 UTC (permalink / raw)
To: ak; +Cc: marc, netdev
In-Reply-To: <200605021802.43301.ak@suse.de>
From: Andi Kleen <ak@suse.de>
Date: Tue, 2 May 2006 18:02:43 +0200
> On Tuesday 02 May 2006 18:19, Just Marc wrote:
>
> > I thought that maybe it's time to either set TCP_DEBUG to 0 or
> > alternatively allow an admin to toggle the printing of this message
> > off/on? On a few busy web servers running usually latest versions of
> > 2.6 I have this message displaying hundreds (if not more) times a day,
>
> You're talking to a lot of broken TCP clients then.
Herbert Xu also fixed a bug that would cause that message
to be emitted erroneously, 9 times out of 10 that is why
people are seeing these messages.
I think disabling that message is a non-starter, we want to
see the message because as we've seen it can point to bugs
on our end too.
^ permalink raw reply
* Re: VJ Channel API - driver level (PATCH)
From: David S. Miller @ 2006-05-03 6:47 UTC (permalink / raw)
To: shemminger; +Cc: alex, netdev
In-Reply-To: <20060502160058.7af02254@localhost.localdomain>
I don't think we should be defining driver APIs when we haven't even
figured out how the core of it would even work yet.
A key part of this is the netfilter bits, that will require
non-trivial flow identification, a hash will simply not be enough, and
it will not be allowed to not support the netfilter bits properly
since everyone will have netfilter enabled in one way or another.
^ permalink raw reply
* Re: VJ Channel API - driver level (README)
From: David S. Miller @ 2006-05-03 6:49 UTC (permalink / raw)
To: alex; +Cc: netdev
In-Reply-To: <4457E2E1.3030809@neterion.com>
BTW another thing to keep in mind, besides the fact that we should be
designing driver APIs at this point at all, is that no implementation
should do MMIOs to the card to insert or delete netchannel lookup
entries.
Rather, it should be communicated to the card in a lazy fashion using
DMA.
Otherwise, net channels will have the same connection rate performance
problems that TOE has.
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Andi Kleen @ 2006-05-03 6:52 UTC (permalink / raw)
To: David S. Miller; +Cc: marc, netdev
In-Reply-To: <20060502.233246.92272407.davem@davemloft.net>
On Wednesday 03 May 2006 08:32, David S. Miller wrote:
> From: Andi Kleen <ak@suse.de>
> Date: Tue, 2 May 2006 18:02:43 +0200
>
> > On Tuesday 02 May 2006 18:19, Just Marc wrote:
> >
> > > I thought that maybe it's time to either set TCP_DEBUG to 0 or
> > > alternatively allow an admin to toggle the printing of this message
> > > off/on? On a few busy web servers running usually latest versions of
> > > 2.6 I have this message displaying hundreds (if not more) times a day,
> >
> > You're talking to a lot of broken TCP clients then.
>
> Herbert Xu also fixed a bug that would cause that message
> to be emitted erroneously, 9 times out of 10 that is why
> people are seeing these messages.
Still if Marc has hundreds per day that would be still tens
per day - and someone with even more traffic than Marc
would have hundreds per day again.
> I think disabling that message is a non-starter, we want to
> see the message because as we've seen it can point to bugs
> on our end too.
Just having the counter would help with that already, no?
Also the default for the sysctl could be maybe switched in -rc* and final?
-Andi
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-03 7:05 UTC (permalink / raw)
To: Just Marc; +Cc: herbert, netdev
In-Reply-To: <445835BB.4050000@corky.net>
Just Marc <marc@corky.net> wrote:
>
> We're now at 2.6.16.12 and it is still showing thousands of times a day
> on a busy web server, have all the bugs been discovered yet?
There are no known bugs on the RX side in 2.6.16 that would cause this.
The few busy web servers that I have access to do not see this message
at all.
So either your web server is somehow attracting a lot of buggy TCP stacks,
or there could be a dodgy gateway in your path that is mucking with the
TCP windows.
I suggest that you do a tcpdump to see what it looks like. It might turn
out that we do still have a bug on our RX side.
BTW, this message is already under net_ratelimit so I don't see any
urgency in getting rid of it completely. If we're going down the
path of disabling it, we probably should go for something more global
rather than a sysctl that controls this one message.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 8:06 UTC (permalink / raw)
To: David S. Miller; +Cc: ak, netdev
In-Reply-To: <20060502.233246.92272407.davem@davemloft.net>
> From: Andi Kleen <ak@suse.de>
> Date: Tue, 2 May 2006 18:02:43 +0200
>
>
>> On Tuesday 02 May 2006 18:19, Just Marc wrote:
>>
>>
>>> I thought that maybe it's time to either set TCP_DEBUG to 0 or
>>> alternatively allow an admin to toggle the printing of this message
>>> off/on? On a few busy web servers running usually latest versions of
>>> 2.6 I have this message displaying hundreds (if not more) times a day,
>>>
>> You're talking to a lot of broken TCP clients then.
>>
>
> Herbert Xu also fixed a bug that would cause that message
> to be emitted erroneously, 9 times out of 10 that is why
> people are seeing these messages.
>
> I think disabling that message is a non-starter, we want to
> see the message because as we've seen it can point to bugs
> on our end too.
>
>
Correct, I noticed this was applied to 2.6.14, however, I am running
2.6.16 (and now 2.6.16.12) on all of the machines in question, I am
seeing hundreds of these messages a day...
Thanks
^ permalink raw reply
* Re: [PATCH] au1000_eth.c Power Management, driver registration and module support
From: Rodolfo Giometti @ 2006-05-03 7:47 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: jgarzik, netdev, Linux-MIPS
In-Reply-To: <20060502150914.GE20543@gundam.enneenne.com>
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]
Hello,
yesterday I did a little mess with GIT... now the patch is
complete. Sorry. :)
I forgot also to say that it has been done against
«linux-2.6.16-stable» branch.
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@gnudd.com
Embedded Systems giometti@linux.it
UNIX programming phone: +39 349 2432127
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 3/9] natsemi: Add support for using MII port with no PHY
From: Jeff Garzik @ 2006-05-03 11:07 UTC (permalink / raw)
To: Jeff Garzik, akpm, netdev, jgarzik, thockin
In-Reply-To: <20060428130139.GA20068@sirena.org.uk>
Mark Brown wrote:
> On Thu, Apr 27, 2006 at 05:54:58AM -0400, Jeff Garzik wrote:
>
>>> Provide a module option which configures the natsemi driver to use the
>>> external MII port on the chip but ignore any PHYs that may be attached to
>>> it. The link state will be left as it was when the driver started and can
>
>> The proper way to do this is via the force_media boolean flag found in
>> several net drivers.
>
> I've had a look at several of the net drivers that implement this option
> (e100, smc91x, starfire and the shared code in mii.c). Unless I'm
> misreading the code it looks like the effect of this option in those
> drivers is to disable autonegotiation but still configure the PHY when
> the NIC is configured.
>
> That is a subset of what the patch does and isn't sufficient for the
> hardware this patch targets: sometimes there may be a PHY visible on the
> MII bus but with a different configuration to the natsemi or there may
> be no PHY present at all. In this case the code in the natsemi driver
> that configures the PHY to match the configuration of the natsemi also
> needs to be disabled.
>
> It looks like I should implement a force_media option and redo this
> patch to use that.
That's the sort of patch I'm looking for...
Jeff
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Ingo Oeser @ 2006-05-03 11:47 UTC (permalink / raw)
To: Herbert Xu; +Cc: Just Marc, netdev
In-Reply-To: <E1FbBPy-0007Iu-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> BTW, this message is already under net_ratelimit so I don't see any
> urgency in getting rid of it completely. If we're going down the
> path of disabling it, we probably should go for something more global
> rather than a sysctl that controls this one message.
Already there: /proc/sys/net/core/{message_cost,message_burst}
Just set burst to 0 and cost to a very big value to basically supppress
all net_ratelimit()ed messages.
Or did you think of sth. else?
Regards
Ingo Oeser
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 12:49 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <E1FbBPy-0007Iu-00@gondolin.me.apana.org.au>
Hi,
> Just Marc <marc@corky.net> wrote:
>
>> We're now at 2.6.16.12 and it is still showing thousands of times a day
>> on a busy web server, have all the bugs been discovered yet?
>>
>
> There are no known bugs on the RX side in 2.6.16 that would cause this.
> The few busy web servers that I have access to do not see this message
> at all.
>
> So either your web server is somehow attracting a lot of buggy TCP stacks,
> or there could be a dodgy gateway in your path that is mucking with the
> TCP windows.
>
>
You're right, actually this box serves http/ftp file transfers only,
it's a mirror with a large amount of downloads a day.
On a pure html/image web server that is just as busy, there are only a
few of these messages, one or two a day.
> I suggest that you do a tcpdump to see what it looks like. It might turn
> out that we do still have a bug on our RX side.
>
I gave it another look, many of the prints are repeat prints for the
same remote IPs,
> BTW, this message is already under net_ratelimit so I don't see any
> urgency in getting rid of it completely. If we're going down the
> path of disabling it, we probably should go for something more global
> rather than a sysctl that controls this one message.
>
I agree, however, I think it's pretty good to allow an admin to toggle
it off completely. Maybe that's all we need, really.
Thanks
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-03 11:56 UTC (permalink / raw)
To: Just Marc; +Cc: netdev
In-Reply-To: <4458A6C1.90103@corky.net>
On Wed, May 03, 2006 at 01:49:05PM +0100, Just Marc wrote:
>
> You're right, actually this box serves http/ftp file transfers only,
> it's a mirror with a large amount of downloads a day.
That's interesting. The RX bug that I fixed earlier would usually
manifest itself under exactly these conditions. Alas you're running
a fixed kernel.
> I gave it another look, many of the prints are repeat prints for the
> same remote IPs,
Can you take a tcpdump of the TCP sessions involving those IPs and
then show me the sections that occur when those messages are triggered?
> I agree, however, I think it's pretty good to allow an admin to toggle
> it off completely. Maybe that's all we need, really.
The question is always what you want to be off and what to leave on.
After all, you can turn off all printk's to the console through /proc.
If you also tell klogd to ignore them then you won't see anything at
all (unless you run dmesg).
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: net/d80211 and management interface (wmaster0ap)
From: Jiri Benc @ 2006-05-03 12:08 UTC (permalink / raw)
To: Jouni Malinen; +Cc: netdev
In-Reply-To: <20060502183930.GA28777@instant802.com>
On Tue, 2 May 2006 11:39:30 -0700, Jouni Malinen wrote:
> It looks like one of your patches in wireless-dev.git broke management
> interface. I'm not completely sure about how this was supposed to work,
> but are the low-level drivers now expected to accept
> IEEE80211_IF_TYPE_MGMT in add_interface handler or should ieee80211.c be
> modified to accept wmaster0ap to be set UP without asking the low-level
> driver?
It shouldn't ask the driver. This was a part of the dropped patch for
removing default management device. I will send a patch to address this
particular issue later today.
> In addition to this, it looked like sending packets from wmaster0ap did
> not work. The packets were being dropped since originating device
> (wmaster0ap) did not match in is_ieee80211_device(). This function
> seemed to use wireless_handlers pointer for recognizing interfaces which
> (like to comment says) is not that nice. wireless_handlers were not set
> for apdev, so the patch below adds it to make TX work through
> wmaster0ap.
Oh, thanks for finding this. But we probably don't want wmaster0ap to
have wireless_handlers set. I will try to rewrite is_ieee80211_device in
some another way.
Thanks,
Jiri
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 13:08 UTC (permalink / raw)
To: Ingo Oeser; +Cc: netdev
In-Reply-To: <200605031347.31281.netdev@axxeo.de>
Hi
> Herbert Xu wrote:
>
>> BTW, this message is already under net_ratelimit so I don't see any
>> urgency in getting rid of it completely. If we're going down the
>> path of disabling it, we probably should go for something more global
>> rather than a sysctl that controls this one message.
>>
>
> Already there: /proc/sys/net/core/{message_cost,message_burst}
>
> Just set burst to 0 and cost to a very big value to basically supppress
> all net_ratelimit()ed messages.
>
> Or did you think of sth. else?
>
That's good, but it may (and probably will) suppress many other messages
which may be of more interest...
Marc
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-03 12:11 UTC (permalink / raw)
To: Just Marc; +Cc: netdev, netdev
In-Reply-To: <4458AB57.6060706@corky.net>
Just Marc <marc@corky.net> wrote:
>
> That's good, but it may (and probably will) suppress many other messages
> which may be of more interest...
That's the crux of the matter. There is no way we can satisfy everyone
short of putting a knob on each individual printk.
So the only solution is to do the filtering yourself in userspace through
klogd/syslogd.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 13:11 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20060503115653.GA1353@gondor.apana.org.au>
Hi
> On Wed, May 03, 2006 at 01:49:05PM +0100, Just Marc wrote:
>
>> You're right, actually this box serves http/ftp file transfers only,
>> it's a mirror with a large amount of downloads a day.
>>
>
> That's interesting. The RX bug that I fixed earlier would usually
> manifest itself under exactly these conditions. Alas you're running
> a fixed kernel.
>
>
>> I gave it another look, many of the prints are repeat prints for the
>> same remote IPs,
>>
>
> Can you take a tcpdump of the TCP sessions involving those IPs and
> then show me the sections that occur when those messages are triggered?
>
>
OK, I'll try that.
>> I agree, however, I think it's pretty good to allow an admin to toggle
>> it off completely. Maybe that's all we need, really.
>>
>
> The question is always what you want to be off and what to leave on.
> After all, you can turn off all printk's to the console through /proc.
> If you also tell klogd to ignore them then you won't see anything at
> all (unless you run dmesg).
>
The problem is that it's really BAD to suppress all messages, there may
be critical ones. In my opinion while the treason uncloaked message can
help uncover bugs it is mostly redundant on a day to day usage for
probably 99% of the scenarios.
Marc
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Alexey Toptygin @ 2006-05-03 12:15 UTC (permalink / raw)
To: Herbert Xu; +Cc: Just Marc, netdev
In-Reply-To: <20060503115653.GA1353@gondor.apana.org.au>
On Wed, 3 May 2006, Herbert Xu wrote:
> Can you take a tcpdump of the TCP sessions involving those IPs and
> then show me the sections that occur when those messages are triggered?
I'm curious, how would you do this without filling the disk? With a script
that starts tcpdump to a ring in the background, waits for the offending
log entry to appear and then kills tcpdump?
Alexey
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-03 12:21 UTC (permalink / raw)
To: Ingo Oeser; +Cc: Just Marc, netdev
In-Reply-To: <200605031347.31281.netdev@axxeo.de>
On Wed, May 03, 2006 at 01:47:31PM +0200, Ingo Oeser wrote:
>
> Already there: /proc/sys/net/core/{message_cost,message_burst}
>
> Just set burst to 0 and cost to a very big value to basically supppress
> all net_ratelimit()ed messages.
>
> Or did you think of sth. else?
No that'll do just fine.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Just Marc @ 2006-05-03 13:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netdev
In-Reply-To: <E1FbGCo-0000OS-00@gondolin.me.apana.org.au>
Hi
> Just Marc <marc@corky.net> wrote:
>
>>
>> That's good, but it may (and probably will) suppress many other messages
>> which may be of more interest...
>>
>
> That's the crux of the matter. There is no way we can satisfy everyone
> short of putting a knob on each individual printk.
>
> So the only solution is to do the filtering yourself in userspace through
> klogd/syslogd.
>
It is the crux of the matter. This print is a purely informational one,
absolutely harmless (unless I'm mistaken) and clogs kernel logs
throughout the universe :)
Seriously, other kernel prints are usually not so harmless and are
generally more important to see. Let me put it another way, except
this print, I have no other prints whatsoever on any of my machines and
if there are prints, I usually do want to know about them, I learned to
ignore this print over the years. I believe many people are in the
same boat.
That's my opinion, anyway.
Thanks
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: Andrew Morton @ 2006-05-03 12:43 UTC (permalink / raw)
To: Pekka Enberg; +Cc: dvrabel, romieu, linux-kernel, netdev, david
In-Reply-To: <1146475901.11271.3.camel@localhost>
On Mon, 01 May 2006 12:31:40 +0300
Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> [PATCH] IP1000 Gigabit Ethernet device driver
>
> This is a cleaned up fork of the IP1000A device driver:
>
> http://www.icplus.com.tw/driver-pp-IP1000A.html
Please remember that to merge this we'll need a signed-off-by from the
original developers. (That's not very gplish, but such is life).
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: Pekka J Enberg @ 2006-05-03 13:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: dvrabel, romieu, linux-kernel, netdev, david
In-Reply-To: <20060503054300.b5e8b95f.akpm@osdl.org>
On Wed, 3 May 2006, Andrew Morton wrote:
> Please remember that to merge this we'll need a signed-off-by from the
> original developers. (That's not very gplish, but such is life).
OK. Lets see if we can track one of them developers down. I see Craig
Rich's email (only email found in the original mail) is out of date so if
anyone knows how to reach him, please let me know. Thanks!
Pekka
^ permalink raw reply
* Re: [PATCH] ipg: removing more dead code
From: Pekka J Enberg @ 2006-05-03 13:12 UTC (permalink / raw)
To: David Gómez; +Cc: Francois Romieu, David Vrabel, linux-kernel, netdev
In-Reply-To: <20060502223048.GA32038@fargo>
Hi David,
On Wed, 3 May 2006, David Gómezz wrote:
> I'll test it tomorrow ASAP. For now, here is another patch removing
> more dead code. This code is never reached (NOTGRACE is not defined)
> and the *fiber_detect functions are subsequently never used.
No need to resend this one, but in future, please follow the proper patch
format:
http://www.zipworld.com.au/~akpm/linux/patches/stuff/tpp.txt
Pekka
^ permalink raw reply
* Re: Disabling "TCP Treason uncloaked"
From: Herbert Xu @ 2006-05-03 13:19 UTC (permalink / raw)
To: Alexey Toptygin; +Cc: Just Marc, netdev
In-Reply-To: <Pine.NEB.4.62.0605031206040.18261@otaku.freeshell.org>
On Wed, May 03, 2006 at 12:15:30PM +0000, Alexey Toptygin wrote:
>
> I'm curious, how would you do this without filling the disk? With a script
> that starts tcpdump to a ring in the background, waits for the offending
> log entry to appear and then kills tcpdump?
Well if you know the set of IPs that's likely to cause this you just
run tcpdump with an expression to filter out all traffic but those
IPs.
Sinec tcpdump only captures 100 bytes of each packet by default, it
should be manageable assuming that this problem occurs relatively
frequently.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RE: VJ Channel API - driver level (PATCH)
From: Leonid Grossman @ 2006-05-03 13:56 UTC (permalink / raw)
To: David S. Miller, shemminger; +Cc: alex, netdev
> -----Original Message-----
> From: netdev-owner@vger.kernel.org
> [mailto:netdev-owner@vger.kernel.org] On Behalf Of David S. Miller
> Sent: Tuesday, May 02, 2006 11:48 PM
> To: shemminger@osdl.org
> Cc: alex@neterion.com; netdev@vger.kernel.org
> Subject: Re: VJ Channel API - driver level (PATCH)
>
>
> I don't think we should be defining driver APIs when we
> haven't even figured out how the core of it would even work yet.
>
> A key part of this is the netfilter bits, that will require
> non-trivial flow identification, a hash will simply not be
> enough, and it will not be allowed to not support the
> netfilter bits properly since everyone will have netfilter
> enabled in one way or another.
Hi Dave,
Do you have suggestions on potential hardware assists/offloads for
netfilter?
I suppose some of it can be worthwhile, although in general may be too
complex to implement - especially above 1 Gig.
I'd expect high end NIC ASICs to implement rx steering based upon some
sort of hash (for load balancing), as well as explicit "1:1" steering
between a sw channel and a hw channel. Both options for channel
configuration are present in the driver interface.
If netfilter assists can be done in hardware, I agree the driver
interface will need to add support for these - otherwise, netfilter
processing will stay above the driver.
> -
> To unsubscribe from this list: send the line "unsubscribe
> netdev" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: IP1000 gigabit nic driver
From: David Vrabel @ 2006-05-03 14:15 UTC (permalink / raw)
To: Pekka J Enberg; +Cc: Andrew Morton, romieu, linux-kernel, netdev, david
In-Reply-To: <Pine.LNX.4.58.0605031605060.19727@sbz-30.cs.Helsinki.FI>
Pekka J Enberg wrote:
> On Wed, 3 May 2006, Andrew Morton wrote:
>> Please remember that to merge this we'll need a signed-off-by from the
>> original developers. (That's not very gplish, but such is life).
>
> OK. Lets see if we can track one of them developers down. I see Craig
> Rich's email (only email found in the original mail) is out of date so if
> anyone knows how to reach him, please let me know. Thanks!
I think/guess that IC Plus bought out Sundance so you'd need to contact
someone at IC Plus.
David Vrabel
^ permalink raw reply
* [PATCH 0/3] d80211: bugfixes, reducing number of interfaces (again)
From: Jiri Benc @ 2006-05-03 15:11 UTC (permalink / raw)
To: netdev; +Cc: John W. Linville
Following patches can be also obtained from:
git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git up
Jiri Benc:
d80211: get rid of default management interface
d80211: use alloc_netdev
d80211: fix is_ieee80211_device
net/d80211/ieee80211.c | 150 +++++++++++++++++++------------------------
net/d80211/ieee80211_i.h | 10 +-
net/d80211/ieee80211_iface.c | 104 ++++++++++++++++++++++-------
3 files changed, 152 insertions(+), 112 deletions(-)
--
Jiri Benc
SUSE Labs
^ 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