* Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
From: Andrew Morton @ 2006-01-27 23:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: kiran, davem, linux-kernel, shai, netdev, pravins
In-Reply-To: <43DAA586.5050609@cosmosbay.com>
Eric Dumazet <dada1@cosmosbay.com> wrote:
>
> Ravikiran G Thirumalai a écrit :
> > On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:
> >> Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> >>> which can be assumed as not frequent.
> >>> At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only
> >>> certain conditions, under memory pressure -- on a large CPU count machine,
> >>> you'd have large memory, and I don't think read_sockets_allocated would get
> >>> called often. It did not atleast on our 8cpu/16G box. So this should be OK
> >>> I think.
> >> That being said, the percpu_counters aren't a terribly successful concept
> >> and probably do need a revisit due to the high inaccuracy at high CPU
> >> counts. It might be better to do some generic version of vm_acct_memory()
> >> instead.
> >
> > AFAICS vm_acct_memory is no better. The deviation on large cpu counts is the
> > same as percpu_counters -- (NR_CPUS * NR_CPUS * 2) ...
>
> Ah... yes you are right, I read min(16, NR_CPUS*2)
So did I ;)
> I wonder if it is not a typo... I mean, I understand the more cpus you have,
> the less updates on central atomic_t is desirable, but a quadratic offset
> seems too much...
I'm not sure whether it was a mistake or if I intended it and didn't do the
sums on accuracy :(
An advantage of retaining a spinlock in percpu_counter is that if accuracy
is needed at a low rate (say, /proc reading) we can take the lock and then
go spill each CPU's local count into the main one. It would need to be a
very low rate though. Or we make the cpu-local counters atomic too.
Certainly it's sensible to delegate the tuning to the creator of the
percpu_counter, but it'll be a difficult thing to get right.
^ permalink raw reply
* Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
From: Andrew Morton @ 2006-01-27 23:08 UTC (permalink / raw)
To: kiran, dada1, davem, linux-kernel, shai, netdev, pravins
In-Reply-To: <20060127150106.38b9e041.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> Oh, and because vm_acct_memory() is counting a singleton object, it can use
> DEFINE_PER_CPU rather than alloc_percpu(), so it saves on a bit of kmalloc
> overhead.
Actually, I don't think that's true. we're allocating a sizeof(long) with
kmalloc_node() so there shouldn't be memory wastage.
^ permalink raw reply
* Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
From: Andrew Morton @ 2006-01-27 23:01 UTC (permalink / raw)
To: Ravikiran G Thirumalai; +Cc: dada1, davem, linux-kernel, shai, netdev, pravins
In-Reply-To: <20060127224433.GB3565@localhost.localdomain>
Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
>
> On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:
> > Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> > >
> > > which can be assumed as not frequent.
> > > At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only
> > > certain conditions, under memory pressure -- on a large CPU count machine,
> > > you'd have large memory, and I don't think read_sockets_allocated would get
> > > called often. It did not atleast on our 8cpu/16G box. So this should be OK
> > > I think.
> >
> > That being said, the percpu_counters aren't a terribly successful concept
> > and probably do need a revisit due to the high inaccuracy at high CPU
> > counts. It might be better to do some generic version of vm_acct_memory()
> > instead.
>
> AFAICS vm_acct_memory is no better. The deviation on large cpu counts is the
> same as percpu_counters -- (NR_CPUS * NR_CPUS * 2) ...
I suppose so. Except vm_acct_memory() has
#define ACCT_THRESHOLD max(16, NR_CPUS * 2)
But if we were to perform similar tuning to percpu_counter, yes, they're
pretty similar.
Oh, and because vm_acct_memory() is counting a singleton object, it can use
DEFINE_PER_CPU rather than alloc_percpu(), so it saves on a bit of kmalloc
overhead.
> >
> > If the benchmarks say that we need to. If we cannot observe any problems
> > in testing of existing code and if we can't demonstrate any benefit from
> > the patched code then one option is to go off and do something else ;)
>
> We first tried plain per-CPU counters for memory_allocated, found that reads
> on memory_allocated was causing cacheline transfers, and then
> switched over to batching. So batching reads is useful. To avoid
> inaccuracy, we can maybe change percpu_counter_init to:
>
> void percpu_counter_init(struct percpu_counter *fbc, int maxdev)
>
> the percpu batching limit would then be maxdev/num_possible_cpus. One would
> use batching counters only when both reads and writes are frequent. With
> the above scheme, we would go fetch cachelines from other cpus for read
> often only on large cpu counts, which is not any worse than the global
> counter alternative, but it would still be beneficial on smaller machines,
> without sacrificing a pre-set deviation.
>
> Comments?
Sounds sane.
^ permalink raw reply
* Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
From: Eric Dumazet @ 2006-01-27 22:58 UTC (permalink / raw)
To: Ravikiran G Thirumalai
Cc: Andrew Morton, davem, linux-kernel, shai, netdev, pravins
In-Reply-To: <20060127224433.GB3565@localhost.localdomain>
Ravikiran G Thirumalai a écrit :
> On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:
>> Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
>>> which can be assumed as not frequent.
>>> At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only
>>> certain conditions, under memory pressure -- on a large CPU count machine,
>>> you'd have large memory, and I don't think read_sockets_allocated would get
>>> called often. It did not atleast on our 8cpu/16G box. So this should be OK
>>> I think.
>> That being said, the percpu_counters aren't a terribly successful concept
>> and probably do need a revisit due to the high inaccuracy at high CPU
>> counts. It might be better to do some generic version of vm_acct_memory()
>> instead.
>
> AFAICS vm_acct_memory is no better. The deviation on large cpu counts is the
> same as percpu_counters -- (NR_CPUS * NR_CPUS * 2) ...
Ah... yes you are right, I read min(16, NR_CPUS*2)
I wonder if it is not a typo... I mean, I understand the more cpus you have,
the less updates on central atomic_t is desirable, but a quadratic offset
seems too much...
Eric
^ permalink raw reply
* Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
From: Ravikiran G Thirumalai @ 2006-01-27 22:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, davem, linux-kernel, shai, netdev, pravins
In-Reply-To: <43DA9EFF.1020200@cosmosbay.com>
On Fri, Jan 27, 2006 at 11:30:23PM +0100, Eric Dumazet wrote:
>
> There are several issues here :
>
> alloc_percpu() current implementation is a a waste of ram. (because it uses
> slab allocations that have a minimum size of 32 bytes)
Oh there was a solution for that :).
http://lwn.net/Articles/119532/
I can quickly revive it if there is interest.
Thanks,
Kiran
^ permalink raw reply
* Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
From: Ravikiran G Thirumalai @ 2006-01-27 22:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: dada1, davem, linux-kernel, shai, netdev, pravins
In-Reply-To: <20060127121602.18bc3f25.akpm@osdl.org>
On Fri, Jan 27, 2006 at 12:16:02PM -0800, Andrew Morton wrote:
> Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
> >
> > which can be assumed as not frequent.
> > At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only
> > certain conditions, under memory pressure -- on a large CPU count machine,
> > you'd have large memory, and I don't think read_sockets_allocated would get
> > called often. It did not atleast on our 8cpu/16G box. So this should be OK
> > I think.
>
> That being said, the percpu_counters aren't a terribly successful concept
> and probably do need a revisit due to the high inaccuracy at high CPU
> counts. It might be better to do some generic version of vm_acct_memory()
> instead.
AFAICS vm_acct_memory is no better. The deviation on large cpu counts is the
same as percpu_counters -- (NR_CPUS * NR_CPUS * 2) ...
>
> If the benchmarks say that we need to. If we cannot observe any problems
> in testing of existing code and if we can't demonstrate any benefit from
> the patched code then one option is to go off and do something else ;)
We first tried plain per-CPU counters for memory_allocated, found that reads
on memory_allocated was causing cacheline transfers, and then
switched over to batching. So batching reads is useful. To avoid
inaccuracy, we can maybe change percpu_counter_init to:
void percpu_counter_init(struct percpu_counter *fbc, int maxdev)
the percpu batching limit would then be maxdev/num_possible_cpus. One would
use batching counters only when both reads and writes are frequent. With
the above scheme, we would go fetch cachelines from other cpus for read
often only on large cpu counts, which is not any worse than the global
counter alternative, but it would still be beneficial on smaller machines,
without sacrificing a pre-set deviation.
Comments?
Thanks,
Kiran
^ permalink raw reply
* Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
From: Eric Dumazet @ 2006-01-27 22:30 UTC (permalink / raw)
To: Andrew Morton
Cc: Ravikiran G Thirumalai, davem, linux-kernel, shai, netdev,
pravins
In-Reply-To: <20060127121602.18bc3f25.akpm@osdl.org>
Andrew Morton a écrit :
> Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
>> On Fri, Jan 27, 2006 at 09:53:53AM +0100, Eric Dumazet wrote:
>>> Ravikiran G Thirumalai a écrit :
>>>> Change the atomic_t sockets_allocated member of struct proto to a
>>>> per-cpu counter.
>>>>
>>>> Signed-off-by: Pravin B. Shelar <pravins@calsoftinc.com>
>>>> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
>>>> Signed-off-by: Shai Fultheim <shai@scalex86.org>
>>>>
>>> Hi Ravikiran
>>>
>>> If I correctly read this patch, I think there is a scalability problem.
>>>
>>> On a big SMP machine, read_sockets_allocated() is going to be a real killer.
>>>
>>> Say we have 128 Opterons CPUS in a box.
>> read_sockets_allocated is being invoked when when /proc/net/protocols is read,
>> which can be assumed as not frequent.
>> At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only
>> certain conditions, under memory pressure -- on a large CPU count machine,
>> you'd have large memory, and I don't think read_sockets_allocated would get
>> called often. It did not atleast on our 8cpu/16G box. So this should be OK
>> I think.
>
> That being said, the percpu_counters aren't a terribly successful concept
> and probably do need a revisit due to the high inaccuracy at high CPU
> counts. It might be better to do some generic version of vm_acct_memory()
> instead.
There are several issues here :
alloc_percpu() current implementation is a a waste of ram. (because it uses
slab allocations that have a minimum size of 32 bytes)
Currently we cannot use per_cpu(&some_object, cpu), so a generic version of
vm_acct_memory() would need a rework of percpu.h and maybe this is not
possible on every platform ?
#define per_cpu(var, cpu) (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
-->
#define per_cpu_name(var) per_cpu__##var
#define per_cpu_addr(var) &per_cpu_name(var)
#define per_cpu(var, cpu) (*RELOC_HIDE(per_cpu_addr(var), __per_cpu_offset[cpu])
But this could render TLS migration difficult...
Eric
^ permalink raw reply
* Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
From: Andrew Morton @ 2006-01-27 20:16 UTC (permalink / raw)
To: Ravikiran G Thirumalai; +Cc: dada1, davem, linux-kernel, shai, netdev, pravins
In-Reply-To: <20060127195227.GA3565@localhost.localdomain>
Ravikiran G Thirumalai <kiran@scalex86.org> wrote:
>
> On Fri, Jan 27, 2006 at 09:53:53AM +0100, Eric Dumazet wrote:
> > Ravikiran G Thirumalai a écrit :
> > >Change the atomic_t sockets_allocated member of struct proto to a
> > >per-cpu counter.
> > >
> > >Signed-off-by: Pravin B. Shelar <pravins@calsoftinc.com>
> > >Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
> > >Signed-off-by: Shai Fultheim <shai@scalex86.org>
> > >
> > Hi Ravikiran
> >
> > If I correctly read this patch, I think there is a scalability problem.
> >
> > On a big SMP machine, read_sockets_allocated() is going to be a real killer.
> >
> > Say we have 128 Opterons CPUS in a box.
>
> read_sockets_allocated is being invoked when when /proc/net/protocols is read,
> which can be assumed as not frequent.
> At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only
> certain conditions, under memory pressure -- on a large CPU count machine,
> you'd have large memory, and I don't think read_sockets_allocated would get
> called often. It did not atleast on our 8cpu/16G box. So this should be OK
> I think.
That being said, the percpu_counters aren't a terribly successful concept
and probably do need a revisit due to the high inaccuracy at high CPU
counts. It might be better to do some generic version of vm_acct_memory()
instead.
If the benchmarks say that we need to. If we cannot observe any problems
in testing of existing code and if we can't demonstrate any benefit from
the patched code then one option is to go off and do something else ;)
^ permalink raw reply
* Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
From: Ravikiran G Thirumalai @ 2006-01-27 19:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, davem, linux-kernel, shai, netdev, pravins
In-Reply-To: <43D9DFA1.9070802@cosmosbay.com>
On Fri, Jan 27, 2006 at 09:53:53AM +0100, Eric Dumazet wrote:
> Ravikiran G Thirumalai a écrit :
> >Change the atomic_t sockets_allocated member of struct proto to a
> >per-cpu counter.
> >
> >Signed-off-by: Pravin B. Shelar <pravins@calsoftinc.com>
> >Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
> >Signed-off-by: Shai Fultheim <shai@scalex86.org>
> >
> Hi Ravikiran
>
> If I correctly read this patch, I think there is a scalability problem.
>
> On a big SMP machine, read_sockets_allocated() is going to be a real killer.
>
> Say we have 128 Opterons CPUS in a box.
read_sockets_allocated is being invoked when when /proc/net/protocols is read,
which can be assumed as not frequent.
At sk_stream_mem_schedule(), read_sockets_allocated() is invoked only
certain conditions, under memory pressure -- on a large CPU count machine,
you'd have large memory, and I don't think read_sockets_allocated would get
called often. It did not atleast on our 8cpu/16G box. So this should be OK
I think.
There're no 128 CPU Opteron boxes yet afaik ;).
Thanks,
Kiran
^ permalink raw reply
* [GIT PULL] bcm43xx update
From: Michael Buesch @ 2006-01-27 17:42 UTC (permalink / raw)
To: John W. Linville
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, bcm43xx-dev-0fE9KPoRgkgATYTw5x5z8w
[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]
Hi John,
I synced my git repository with the bcm43xx SVN repository.
I will continue to develop the driver in git, so these ugly syncing
will not be needed any longer. I will poke you from time to time
to pull from my repos. (I don't know how the other bcm43xx developers
will handle it. I suggest they set up a git repository, too)
Please do a
git pull git://bu3sch.de/bcm43xx.git master-upstream
to pull the bcm43xx-softmac branch.
Please do a
git pull git://bu3sch.de/bcm43xx.git dscape-upstream
to pull the bcm43xx-dscape branch.
master ShortLog:
Michael Buesch:
[bcm43xx] sync with svn.berlios.de
[bcm43xx] remove linux version compatibility code.
[bcm43xx] Move README file to Documentation directory.
[bcm43xx] remove redundant COPYING file.
dscape ShortLog:
Michael Buesch:
[bcm43xx] sync with svn.berlios.de
[bcm43xx] Move documentation to Documentation subdirectory and move scripts to scripts subdirectory.
[bcm43xx] Remove redundant COPYING file.
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2.6.15-git9a] aoe [1/1]: do not stop retransmit timer when device goes down
From: Al Boldi @ 2006-01-27 16:12 UTC (permalink / raw)
To: Ed L. Cashin; +Cc: linux-kernel, linux-raid, netdev
In-Reply-To: <200601260104.37649.a1426z@gawab.com>
Ed L. Cashin wrote:
> On Thu, Jan 26, 2006 at 01:04:37AM +0300, Al Boldi wrote:
> > Ed L. Cashin wrote:
> > > This patch is a bugfix that follows and depends on the
> > > eight aoe driver patches sent January 19th.
> >
> > Will they also fix this?
> > Or is this an md bug?
>
> No, this patch fixes a bug that would cause an AoE device to be
> totally unusable, so I think mdadm or mkraid would get an error that
> the device was not available before it tried to make a new md device.
>
> > It only happens with aoe.
>
> It looks like in setting up the raid, sysfs_create_link probably has
> this going off:
>
> BUG_ON(!kobj || !kobj->dentry || !name);
>
> > Also, why is aoe slower than nbd?
>
> It wasn't when I tried it. The userland vblade is slow. Maybe that's
> affecting your results?
Why is the userland vblade server slower than the userland nbd-server?
Thanks!
--
Al
^ permalink raw reply
* Re: [BUG] sky2 broken for Yukon PCI-E Gigabit Ethernet Controller 11ab:4362 (rev 19)
From: Knut Petersen @ 2006-01-27 16:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: shemminger, netdev, linux-kernel, David S. Miller
In-Reply-To: <20060127122242.GA32128@gondor.apana.org.au>
Herbert Xu wrote:
>When we pull the PPP protocol off the skb, we forgot to update the
>hardware RX checksum. This may lead to messages such as
>
> dsl0: hw csum failure.
>
>Similarly, we need to clear the hardware checksum flag when we use
>the existing packet to store the decompressed result.
>
>Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
ACK
That patch seems to solve all my problems with
sky2 / pppoe / SuSE 9.2 Firewall.
Thanks a lot!
cu,
Knut
^ permalink raw reply
* Re: [BUG] sky2 broken for Yukon PCI-E Gigabit Ethernet Controller 11ab:4362 (rev 19)
From: Patrick McHardy @ 2006-01-27 15:28 UTC (permalink / raw)
To: Herbert Xu, KdF
Cc: Knut Petersen, shemminger, netdev, linux-kernel, David S. Miller,
netfilter-devel
In-Reply-To: <20060127122242.GA32128@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
Herbert Xu wrote:
> On Fri, Jan 27, 2006 at 07:07:34AM +0100, Knut Petersen wrote:
>
>>Well, there are no problems if SuSEfirewall2 is disabled. But have a look
>>at the loaded modules:
>>
>>ipt_MASQUERADE 3968 1
>>pppoe 15360 2
>>pppox 4616 1 pppoe
>
>
> OK, although we can't rule out sky2/netfilter from the enquiry, I've
> identified two bugs in ppp/pppoe that may be responsible for what you
> are seeing. So please try the following patch and let us know if the
> problem still exists (or deteriorates/improves).
>
> [PPP]: Fixed hardware RX checksum handling
>
> When we pull the PPP protocol off the skb, we forgot to update the
> hardware RX checksum. This may lead to messages such as
>
> dsl0: hw csum failure.
>
> Similarly, we need to clear the hardware checksum flag when we use
> the existing packet to store the decompressed result.
We had a couple of reports of incorrect hardware checksums with
PPPoE. KdF, can you test Herbert's patch (attached again to this
mail) please?
[-- Attachment #2: ppp-rxcsum --]
[-- Type: text/plain, Size: 682 bytes --]
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -1610,6 +1610,8 @@ ppp_receive_nonmp_frame(struct ppp *ppp,
}
else if (!pskb_may_pull(skb, skb->len))
goto err;
+ else
+ skb->ip_summed = CHECKSUM_NONE;
len = slhc_uncompress(ppp->vj, skb->data + 2, skb->len - 2);
if (len <= 0) {
@@ -1690,6 +1692,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp,
kfree_skb(skb);
} else {
skb_pull(skb, 2); /* chop off protocol */
+ skb_postpull_rcsum(skb, skb->data - 2, 2);
skb->dev = ppp->dev;
skb->protocol = htons(npindex_to_ethertype[npi]);
skb->mac.raw = skb->data;
^ permalink raw reply
* Re: [Acx100-devel] Re: [-mm patch] drivers/net/wireless/tiacx/: remove code for WIRELESS_EXT < 18
From: Andreas Mohr @ 2006-01-27 14:46 UTC (permalink / raw)
To: acx100-devel
Cc: Johannes Berg, Adrian Bunk, John W. Linville, jgarzik, netdev,
linux-kernel
In-Reply-To: <200601271449.49226.vda@ilport.com.ua>
Hi,
On Fri, Jan 27, 2006 at 02:49:49PM +0200, Denis Vlasenko wrote:
> On Friday 27 January 2006 13:49, Johannes Berg wrote:
> > On Fri, 2006-01-27 at 12:19 +0200, Denis Vlasenko wrote:
> >
> > > I very much want to get rid of all remaining compat cruft, and
> > > I plan to do it as soon as acx will be present in mainline kernel.
> >
> > I doubt you'll get it merged with the compat cruft.
>
> What cruft? This?
>
> # grep -r WIRELESS_EXT .
> ./pci.c: ndev->name, WIRELESS_EXT, UTS_RELEASE);
> ./common.c: "Wireless extension version:\t" STRING(WIRELESS_EXT) "\n"
> ./acx_struct.h:#ifdef WIRELESS_EXT
> ./acx_struct.h:#if WIRELESS_EXT > 15
> ./ioctl.c: range->we_version_compiled = WIRELESS_EXT;
>
> I consider this to be a really modest amount of compat code
> which makes driver users happy (that fraction of it which is not
> willing to run -mm).
>
> However, I would remove even that at Jeff's or Andrew's request,
> or without anyone's request if acx will be merged to Linus tree.
Indeed, I don't think there should be any discussion at all about this,
since it helps users of our currently still external driver
(not too much longer external, I guess and hope) a lot.
Given that we don't have a stable driver ABI (for way too often discussed
very valid and sane reasons) I really, really think we shouldn't shoot
our foot into pieces by then additionally also bitching about *MINIMAL*
amounts of compatibility code required to keep up with those speedily changing
kernel requirements while our driver isn't included yet.
In the future, I'd like to ask people to be a *bit* more tolerant of newish
compatibility cruft. It's not like we're supporting kernel 2.2.x here still,
our driver is at 2.6.10 at a minimum(!), yet you still want to remove even
those few pieces!
This is simply ridiculous (again, as long as our driver isn't merged, which it
should be soon to improve maintenance).
OK, ending this rather fruitless discussion here. I better get back to hacking,
that's more productive.
Andreas Mohr
^ permalink raw reply
* Re: [-mm patch] drivers/net/wireless/tiacx/: remove code for WIRELESS_EXT < 18
From: Denis Vlasenko @ 2006-01-27 12:49 UTC (permalink / raw)
To: Johannes Berg
Cc: Adrian Bunk, acx100-devel, John W. Linville, jgarzik, netdev,
linux-kernel
In-Reply-To: <1138362557.5983.26.camel@localhost>
On Friday 27 January 2006 13:49, Johannes Berg wrote:
> On Fri, 2006-01-27 at 12:19 +0200, Denis Vlasenko wrote:
>
> > I very much want to get rid of all remaining compat cruft, and
> > I plan to do it as soon as acx will be present in mainline kernel.
>
> I doubt you'll get it merged with the compat cruft.
What cruft? This?
# grep -r WIRELESS_EXT .
./pci.c: ndev->name, WIRELESS_EXT, UTS_RELEASE);
./common.c: "Wireless extension version:\t" STRING(WIRELESS_EXT) "\n"
./acx_struct.h:#ifdef WIRELESS_EXT
./acx_struct.h:#if WIRELESS_EXT > 15
./ioctl.c: range->we_version_compiled = WIRELESS_EXT;
I consider this to be a really modest amount of compat code
which makes driver users happy (that fraction of it which is not
willing to run -mm).
However, I would remove even that at Jeff's or Andrew's request,
or without anyone's request if acx will be merged to Linus tree.
--
vda
^ permalink raw reply
* Re: [BUG] sky2 broken for Yukon PCI-E Gigabit Ethernet Controller 11ab:4362 (rev 19)
From: Herbert Xu @ 2006-01-27 12:22 UTC (permalink / raw)
To: Knut Petersen; +Cc: shemminger, netdev, linux-kernel, David S. Miller
In-Reply-To: <43D9B8A6.5020200@t-online.de>
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]
On Fri, Jan 27, 2006 at 07:07:34AM +0100, Knut Petersen wrote:
>
> Well, there are no problems if SuSEfirewall2 is disabled. But have a look
> at the loaded modules:
>
> ipt_MASQUERADE 3968 1
> pppoe 15360 2
> pppox 4616 1 pppoe
OK, although we can't rule out sky2/netfilter from the enquiry, I've
identified two bugs in ppp/pppoe that may be responsible for what you
are seeing. So please try the following patch and let us know if the
problem still exists (or deteriorates/improves).
[PPP]: Fixed hardware RX checksum handling
When we pull the PPP protocol off the skb, we forgot to update the
hardware RX checksum. This may lead to messages such as
dsl0: hw csum failure.
Similarly, we need to clear the hardware checksum flag when we use
the existing packet to store the decompressed result.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
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
[-- Attachment #2: ppp-rxcsum --]
[-- Type: text/plain, Size: 682 bytes --]
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -1610,6 +1610,8 @@ ppp_receive_nonmp_frame(struct ppp *ppp,
}
else if (!pskb_may_pull(skb, skb->len))
goto err;
+ else
+ skb->ip_summed = CHECKSUM_NONE;
len = slhc_uncompress(ppp->vj, skb->data + 2, skb->len - 2);
if (len <= 0) {
@@ -1690,6 +1692,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp,
kfree_skb(skb);
} else {
skb_pull(skb, 2); /* chop off protocol */
+ skb_postpull_rcsum(skb, skb->data - 2, 2);
skb->dev = ppp->dev;
skb->protocol = htons(npindex_to_ethertype[npi]);
skb->mac.raw = skb->data;
^ permalink raw reply
* Re: [-mm patch] drivers/net/wireless/tiacx/: remove code for WIRELESS_EXT < 18
From: Johannes Berg @ 2006-01-27 11:49 UTC (permalink / raw)
To: Denis Vlasenko
Cc: Adrian Bunk, acx100-devel, John W. Linville, jgarzik, netdev,
linux-kernel
In-Reply-To: <200601271219.24332.vda@ilport.com.ua>
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
On Fri, 2006-01-27 at 12:19 +0200, Denis Vlasenko wrote:
> I very much want to get rid of all remaining compat cruft, and
> I plan to do it as soon as acx will be present in mainline kernel.
I doubt you'll get it merged with the compat cruft.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: 2.6.16-rc1-mm3
From: Reuben Farrelly @ 2006-01-27 11:47 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev
In-Reply-To: <20060124232406.50abccd1.akpm@osdl.org>
On 25/01/2006 8:24 p.m., Andrew Morton wrote:
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc1/2.6.16-rc1-mm3/
>
> - Dropped the timekeeping patch series due to a complex timesource selection
> bug.
>
> - Various fixes and updates.
>
>
>
> Changes since 2.6.16-rc1-mm2:
Just triggered this one, which had a fairly bad effect on connectivity to the box:
i2c /dev entries driver
slab error in kmem_cache_destroy(): cache `ip_conntrack': Can't free all objects
[<b010412b>] show_trace+0xd/0xf
[<b01041cc>] dump_stack+0x17/0x19
[<b0155d04>] kmem_cache_destroy+0x9b/0x1a9
[<f0ebf701>] ip_conntrack_cleanup+0x5d/0x10e [ip_conntrack]
[<f0ebe31e>] init_or_cleanup+0x1f8/0x283 [ip_conntrack]
[<f0ec2c4e>] fini+0xa/0x66 [ip_conntrack]
[<b0136d06>] sys_delete_module+0x161/0x1fb
[<b0102b3f>] sysenter_past_esp+0x54/0x75
Removing netfilter NETLINK layer.
[root@tornado log]#
I was just reading IMAP mail at the time, ie same as I'd been doing for an hour
or two beforehand and not altering config of the box in any way. I was able to
log on via console but lost all network connectivity and had to reboot :(
Generic details such as .config is at http://www.reub.net/files/kernel/
reuben
^ permalink raw reply
* Re: [-mm patch] drivers/net/wireless/tiacx/: remove code for WIRELESS_EXT < 18
From: Denis Vlasenko @ 2006-01-27 10:19 UTC (permalink / raw)
To: Adrian Bunk, acx100-devel; +Cc: John W. Linville, jgarzik, netdev, linux-kernel
In-Reply-To: <20060122171104.GC10003@stusta.de>
Hi Adrian,
On Sunday 22 January 2006 19:11, Adrian Bunk wrote:
> WIRELESS_EXT < 18 will never be true in the kernel.
>
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Please don't do this. We are not in the kernel yet.
acx currently is in -mm, not in mainline.
We have quite a few users of it which aren't using -mm,
but instead compile it out-of-kernel.
We gradually removed 2.4 compat code and most of early 2.6isms.
Even that produced a few complains. Currently out-of-tree acx
is working for any kernel >= 2.6.10.
I very much want to get rid of all remaining compat cruft, and
I plan to do it as soon as acx will be present in mainline kernel.
--
vda
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: [patch 2/4] net: Percpufy frequently used variables -- struct proto.memory_allocated
From: Eric Dumazet @ 2006-01-27 9:01 UTC (permalink / raw)
To: Ravikiran G Thirumalai
Cc: Andrew Morton, davem, linux-kernel, shai, netdev, pravins
In-Reply-To: <20060126190212.GD3651@localhost.localdomain>
Ravikiran G Thirumalai a écrit :
> Change struct proto->memory_allocated to a batching per-CPU counter
> (percpu_counter) from an atomic_t. A batching counter is better than a
> plain per-CPU counter as this field is read often.
>
> Signed-off-by: Pravin B. Shelar <pravins@calsoftinc.com>
> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
> Signed-off-by: Shai Fultheim <shai@scalex86.org>
>
Hello Ravikiran
I like this patch, but I'm not sure current percpu_counter fits the needs.
The percpu_counter_read() can return a value that is off by +-
FBC_BATCH*NR_CPUS, ie 2*(NR_CPUS^2) or 4*(NR_CPUS^2)
if NR_CPUS = 128, the 'error' from percpu_counter_read() is +- 32768
Is it acceptable ?
Thank you
Eric
^ permalink raw reply
* Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
From: Eric Dumazet @ 2006-01-27 8:53 UTC (permalink / raw)
To: Ravikiran G Thirumalai
Cc: Andrew Morton, davem, linux-kernel, shai, netdev, pravins
In-Reply-To: <20060126190357.GE3651@localhost.localdomain>
Ravikiran G Thirumalai a écrit :
> Change the atomic_t sockets_allocated member of struct proto to a
> per-cpu counter.
>
> Signed-off-by: Pravin B. Shelar <pravins@calsoftinc.com>
> Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
> Signed-off-by: Shai Fultheim <shai@scalex86.org>
>
Hi Ravikiran
If I correctly read this patch, I think there is a scalability problem.
On a big SMP machine, read_sockets_allocated() is going to be a real killer.
Say we have 128 Opterons CPUS in a box.
You'll need to bring 128 cache lines (plus 8*128 bytes to read the 128
pointers inside percpu structure)
I think a solution 'a la percpu_counter' is preferable, or even better a
dedicated per_cpu with a threshold management (see mm/swap.c , function
vm_acct_memory() to see how vm_committed_space is updated without too bad SMP
scalability)
Thank you
Eric
^ permalink raw reply
* Re: [BUG] sky2 broken for Yukon PCI-E Gigabit Ethernet Controller 11ab:4362 (rev 19)
From: Knut Petersen @ 2006-01-27 6:07 UTC (permalink / raw)
To: Herbert Xu; +Cc: shemminger, netdev, linux-kernel
In-Reply-To: <E1F1UqC-0002XE-00@gondolin.me.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]
* Herbert Xu wrote:
>Does the problem go away if you disable conntrack by unloading its module?
>
>Please try to capture the offending ICMP packet with tcpdump and show us
>what it looks like.
>
>
Well, there are no problems if SuSEfirewall2 is disabled. But have a look
at the loaded modules:
ipt_MASQUERADE 3968 1
pppoe 15360 2
pppox 4616 1 pppoe
af_packet 23240 2
ppp_generic 30740 6 pppoe,pppox
slhc 7040 1 ppp_generic
ipt_TOS 2816 28
ipt_TCPMSS 4800 2
ipt_LOG 7232 55
ipt_limit 2880 55
ipt_pkttype 1984 4
ipt_state 2240 46
ip6t_LOG 8000 1
ip6t_limit 3008 1
ip6t_REJECT 5824 3
ipt_REJECT 5952 3
iptable_mangle 3200 1
iptable_nat 8836 1
iptable_filter 3264 1
ip6table_mangle 2752 0
ip_nat_ftp 3776 0
ip_nat 18284 3 ipt_MASQUERADE,iptable_nat,ip_nat_ftp
ip_conntrack_ftp 8240 1 ip_nat_ftp
ip_conntrack 51020 6
ipt_MASQUERADE,ipt_state,iptable_nat,ip_nat_ftp,ip_nat,ip_conntrack_ftp
ip_tables 24088 11
ipt_MASQUERADE,ipt_TOS,ipt_TCPMSS,ipt_LOG,ipt_limit,ipt_pkttype,ipt_state,ipt_REJECT,iptable_mangle,iptable_nat,iptable_filter
ip6table_filter 3136 1
ip6_tables 25624 5
ip6t_LOG,ip6t_limit,ip6t_REJECT,ip6table_mangle,ip6table_filter
ipv6 271712 14 ip6t_REJECT
How should I unload ip_conntrack alone?
* Stephen Hemminger wrote:
>Does it always show up on icmp only?
>
>What are the iptables rules (iptables -L)
>
>
>
As far as I can see, all my sky2 problems are gone with -K rx off.
So here is more information. I executed the following script:
logger Starting test
logger "Executing ethtool -K eth0 rx off"
ethtool -K eth0 rx off
logger "Executing tcpdump -i eth0 -vv > tcpdumpfile &"
tcpdump -i eth0 -vv > tcpdumpfile &
logger "Executing host www.suse.com"
host www.suse.com
logger "Sleeping 2 seconds"
sleep 2
logger "Executing ping -c 2 195.135.220.3"
ping -c 2 195.135.220.3
logger "Sleeping 2 seconds"
sleep 2
logger "Executing ethtool -K eth0 rx on"
ethtool -K eth0 rx on
logger "Sleeping 2 seconds"
sleep 2
logger "Executing host www.suse.com"
host www.suse.com
logger "Sleeping 2 seconds"
sleep 2
logger "Executing ping -c 2 195.135.220.3"
ping -c 2 195.135.220.3
logger "Sleeping 2 seconds"
sleep 2
logger "Executing ethtool -K eth0 rx off"
ethtool -K eth0 rx off
logger "Sleeping 2 seconds"
sleep 2
logger "killall tcpdump"
killall tcpdump
logger End of test
The first host and ping worked fine, after the ethtool -K eth0 rx on
the host www.suse.com timed out with
;; connection timed out; no servers could be reached
and the ping 195.135.220.3 provoked the stack traces you see in sky2syslog.
I attach the syslog for the time of the test, the output of iptables -L
and the
output of tcpdump as the very long lines included would be hard to read
with linebreaks.
No, I did _not_ delete anything from the tcpdump file.
cu,
Knut
[-- Attachment #2: sky2syslog --]
[-- Type: text/plain, Size: 5199 bytes --]
Jan 27 06:29:38 linux knut: Starting test
Jan 27 06:29:38 linux knut: Executing ethtool -K eth0 rx off
Jan 27 06:29:38 linux knut: Executing tcpdump -i eth0 -vv > tcpdumpfile &
Jan 27 06:29:38 linux knut: Executing host www.suse.com
Jan 27 06:29:38 linux kernel: [ 403.606906] device eth0 entered promiscuous mode
Jan 27 06:29:38 linux knut: Sleeping 2 seconds
Jan 27 06:29:40 linux knut: Executing ping -c 2 195.135.220.3
Jan 27 06:29:41 linux dhcpd: icmp.c(274): trace_write_packet with null trace type
Jan 27 06:29:42 linux dhcpd: icmp.c(274): trace_write_packet with null trace type
Jan 27 06:29:42 linux knut: Sleeping 2 seconds
Jan 27 06:29:44 linux knut: Executing ethtool -K eth0 rx on
Jan 27 06:29:44 linux knut: Sleeping 2 seconds
Jan 27 06:29:46 linux knut: Executing host www.suse.com
Jan 27 06:29:46 linux kernel: [ 406.693484] SFW2-INext-DROP-DEFLT-INV IN=dsl0 OUT= MAC= SRC=217.237.150.33 DST=84.171.112.100 LEN=74 TOS=0x10 PREC=0x00 TTL=57 ID=53333 PROTO=UDP SPT=53 DPT=1076 LEN=54
Jan 27 06:29:47 linux kernel: [ 407.125112] SFW2-INext-DROP-DEFLT-INV IN=dsl0 OUT= MAC= SRC=217.237.150.33 DST=84.171.112.100 LEN=116 TOS=0x10 PREC=0x00 TTL=57 ID=24213 PROTO=UDP SPT=53 DPT=1078 LEN=96
Jan 27 06:29:58 linux knut: Sleeping 2 seconds
Jan 27 06:30:00 linux knut: Executing ping -c 2 195.135.220.3
Jan 27 06:30:00 linux kernel: [ 412.693613] dsl0: hw csum failure.
Jan 27 06:30:00 linux kernel: [ 412.693615] [<c0104007>] dump_stack+0x17/0x20
Jan 27 06:30:00 linux kernel: [ 412.693628] [<c03b2961>] netdev_rx_csum_fault+0x31/0x40
Jan 27 06:30:00 linux kernel: [ 412.693632] [<c03b00ea>] __skb_checksum_complete+0x5a/0x60
Jan 27 06:30:00 linux kernel: [ 412.693635] [<f88d892e>] icmp_error+0x10e/0x1e0 [ip_conntrack]
Jan 27 06:30:00 linux kernel: [ 412.693644] [<f88d5d82>] ip_conntrack_in+0x72/0x240 [ip_conntrack]
Jan 27 06:30:00 linux kernel: [ 412.693651] [<c03c7347>] nf_iterate+0x57/0x90
Jan 27 06:30:00 linux kernel: [ 412.693654] [<c03c73e5>] nf_hook_slow+0x65/0x120
Jan 27 06:30:00 linux kernel: [ 412.693657] [<c03cdc76>] ip_rcv+0x286/0x510
Jan 27 06:30:00 linux kernel: [ 412.693660] [<c03b31a5>] netif_receive_skb+0x165/0x1c0
Jan 27 06:30:00 linux kernel: [ 412.693663] [<c03b3287>] process_backlog+0x87/0x110
Jan 27 06:30:00 linux kernel: [ 412.693665] [<c03b33bf>] net_rx_action+0xaf/0x100
Jan 27 06:30:00 linux kernel: [ 412.693668] [<c01232d5>] __do_softirq+0x55/0xb0
Jan 27 06:30:00 linux kernel: [ 412.693671] [<c0123363>] do_softirq+0x33/0x40
Jan 27 06:30:00 linux kernel: [ 412.693674] [<c0123453>] irq_exit+0x43/0x50
Jan 27 06:30:00 linux kernel: [ 412.693676] [<c0105218>] do_IRQ+0x38/0x70
Jan 27 06:30:00 linux kernel: [ 412.693679] [<c0103baa>] common_interrupt+0x1a/0x20
Jan 27 06:30:00 linux kernel: [ 412.693682] [<c0101147>] cpu_idle+0x87/0x90
Jan 27 06:30:00 linux kernel: [ 412.693684] [<c0100257>] rest_init+0x37/0x40
Jan 27 06:30:00 linux kernel: [ 412.693686] [<c055e845>] start_kernel+0x195/0x1e0
Jan 27 06:30:00 linux kernel: [ 412.693690] [<c0100199>] 0xc0100199
Jan 27 06:30:00 linux dhcpd: icmp.c(274): trace_write_packet with null trace type
Jan 27 06:30:01 linux kernel: [ 413.121225] dsl0: hw csum failure.
Jan 27 06:30:01 linux kernel: [ 413.121227] [<c0104007>] dump_stack+0x17/0x20
Jan 27 06:30:01 linux kernel: [ 413.121236] [<c03b2961>] netdev_rx_csum_fault+0x31/0x40
Jan 27 06:30:01 linux kernel: [ 413.121240] [<c03b00ea>] __skb_checksum_complete+0x5a/0x60
Jan 27 06:30:01 linux kernel: [ 413.121242] [<f88d892e>] icmp_error+0x10e/0x1e0 [ip_conntrack]
Jan 27 06:30:01 linux kernel: [ 413.121252] [<f88d5d82>] ip_conntrack_in+0x72/0x240 [ip_conntrack]
Jan 27 06:30:01 linux kernel: [ 413.121258] [<c03c7347>] nf_iterate+0x57/0x90
Jan 27 06:30:01 linux kernel: [ 413.121261] [<c03c73e5>] nf_hook_slow+0x65/0x120
Jan 27 06:30:01 linux kernel: [ 413.121264] [<c03cdc76>] ip_rcv+0x286/0x510
Jan 27 06:30:01 linux kernel: [ 413.121267] [<c03b31a5>] netif_receive_skb+0x165/0x1c0
Jan 27 06:30:01 linux kernel: [ 413.121270] [<c03b3287>] process_backlog+0x87/0x110
Jan 27 06:30:01 linux kernel: [ 413.121272] [<c03b33bf>] net_rx_action+0xaf/0x100
Jan 27 06:30:01 linux knut: Sleeping 2 seconds
Jan 27 06:30:01 linux kernel: [ 413.121275] [<c01232d5>] __do_softirq+0x55/0xb0
Jan 27 06:30:01 linux kernel: [ 413.121278] [<c0123363>] do_softirq+0x33/0x40
Jan 27 06:30:01 linux kernel: [ 413.121281] [<c0123453>] irq_exit+0x43/0x50
Jan 27 06:30:01 linux kernel: [ 413.121283] [<c0105218>] do_IRQ+0x38/0x70
Jan 27 06:30:01 linux kernel: [ 413.121286] [<c0103baa>] common_interrupt+0x1a/0x20
Jan 27 06:30:01 linux kernel: [ 413.121288] [<c0101147>] cpu_idle+0x87/0x90
Jan 27 06:30:01 linux kernel: [ 413.121291] [<c0100257>] rest_init+0x37/0x40
Jan 27 06:30:01 linux kernel: [ 413.121293] [<c055e845>] start_kernel+0x195/0x1e0
Jan 27 06:30:01 linux kernel: [ 413.121296] [<c0100199>] 0xc0100199
Jan 27 06:30:01 linux dhcpd: icmp.c(274): trace_write_packet with null trace type
Jan 27 06:30:03 linux knut: Executing ethtool -K eth0 rx off
Jan 27 06:30:03 linux knut: Sleeping 2 seconds
Jan 27 06:30:05 linux knut: killall tcpdump
Jan 27 06:30:05 linux knut: End of test
[-- Attachment #3: tcpdumpfile --]
[-- Type: text/plain, Size: 3558 bytes --]
06:29:38.899532 PPPoE [ses 0x385] IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], length: 58) p54AB7064.dip.t-dialin.net.rdrmshc > www-proxy.F2.srv.t-online.de.domain: [udp sum ok] 22324+ A? www.suse.com. (30)
06:29:38.899812 PPPoE [ses 0x385] IP (tos 0x10, ttl 64, id 51975, offset 0, flags [DF], length: 73) p54AB7064.dip.t-dialin.net.dab-sti-c > www-proxy.F2.srv.t-online.de.domain: [udp sum ok] 2117+ PTR? 33.150.237.217.in-addr.arpa. (45)
06:29:38.946775 PPPoE [ses 0x385] IP (tos 0x0, ttl 57, id 16399, offset 0, flags [none], length: 74) www-proxy.F2.srv.t-online.de.domain > p54AB7064.dip.t-dialin.net.rdrmshc: [udp sum ok] 22324 q: A? www.suse.com. 1/0/0 www.suse.com. A turing.suse.de (46)
06:29:38.955734 PPPoE [ses 0x385] IP (tos 0x0, ttl 57, id 63158, offset 0, flags [none], length: 115) www-proxy.F2.srv.t-online.de.domain > p54AB7064.dip.t-dialin.net.dab-sti-c: 2117 q: PTR? 33.150.237.217.in-addr.arpa. 1/0/0 [|domain]
06:29:38.955816 PPPoE [ses 0x385] IP (tos 0x10, ttl 64, id 52031, offset 0, flags [DF], length: 73) p54AB7064.dip.t-dialin.net.dab-sti-c > www-proxy.F2.srv.t-online.de.domain: [udp sum ok] 2118+ PTR? 100.112.171.84.in-addr.arpa. (45)
06:29:39.009499 PPPoE [ses 0x385] IP (tos 0x0, ttl 57, id 59142, offset 0, flags [none], length: 113) www-proxy.F2.srv.t-online.de.domain > p54AB7064.dip.t-dialin.net.dab-sti-c: 2118 q: PTR? 100.112.171.84.in-addr.arpa. 1/0/0 [|domain]
06:29:39.009587 PPPoE [ses 0x385] IP (tos 0x10, ttl 64, id 52085, offset 0, flags [DF], length: 72) p54AB7064.dip.t-dialin.net.dab-sti-c > www-proxy.F2.srv.t-online.de.domain: [udp sum ok] 2119+ PTR? 3.220.135.195.in-addr.arpa. (44)
06:29:39.055627 PPPoE [ses 0x385] IP (tos 0x0, ttl 57, id 39957, offset 0, flags [none], length: 100) www-proxy.F2.srv.t-online.de.domain > p54AB7064.dip.t-dialin.net.dab-sti-c: 2119 q: PTR? 3.220.135.195.in-addr.arpa. 1/0/0 3.220.135.195.in-addr.arpa. (72)
06:29:40.953234 PPPoE [ses 0x385] IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 84) p54AB7064.dip.t-dialin.net > turing.suse.de: icmp 64: echo request seq 1
06:29:41.022500 PPPoE [ses 0x385] IP (tos 0x0, ttl 55, id 36207, offset 0, flags [none], length: 84) turing.suse.de > p54AB7064.dip.t-dialin.net: icmp 64: echo reply seq 1
06:29:41.952973 PPPoE [ses 0x385] IP (tos 0x0, ttl 64, id 1, offset 0, flags [DF], length: 84) p54AB7064.dip.t-dialin.net > turing.suse.de: icmp 64: echo request seq 2
06:29:42.019352 PPPoE [ses 0x385] IP (tos 0x0, ttl 55, id 36398, offset 0, flags [none], length: 84) turing.suse.de > p54AB7064.dip.t-dialin.net: icmp 64: echo reply seq 2
06:29:42.719838 PPPoE [ses 0x385] LCP, Echo-Request (0x09), id 56, Magic-Num 0x8a5b3542, length 8
0x0000: c021 0938 0008 8a5b 3542
06:29:42.761102 PPPoE [ses 0x385] LCP, Echo-Reply (0x0a), id 56, Magic-Num 0x15c96251, length 8
0x0000: c021 0a38 0008 15c9 6251
06:29:46.031631 PPPoE [ses 0x385] IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], length: 58) p54AB7064.dip.t-dialin.net.dab-sti-c > www-proxy.F2.srv.t-online.de.domain: [udp sum ok] 35750+ A? www.suse.com. (30)
06:29:46.078624 PPPoE [ses 0x385] IP (tos 0x0, ttl 57, id 53333, offset 0, flags [none], length: 74) www-proxy.F2.srv.t-online.de.domain > p54AB7064.dip.t-dialin.net.dab-sti-c: [udp sum ok] 35750 q: A? www.suse.com. 1/0/0 www.suse.com. A turing.suse.de (46)
06:29:47.033244 PPPoE [ses 0x385] IP (tos 0x10, ttl 64, id 0, offset 0, flags [DF], length: 58) p54AB7064.dip.t-dialin.net.imgames > 217.237.151.161.domain: [udp sum ok] 35750+ A? www.suse.com. (30)
[-- Attachment #4: iptablesdump --]
[-- Type: text/plain, Size: 20978 bytes --]
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
input_ext all -- anywhere anywhere
input_int all -- anywhere anywhere
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-IN-ILL-TARGET '
DROP all -- anywhere anywhere
Chain FORWARD (policy DROP)
target prot opt source destination
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
forward_ext all -- anywhere anywhere
forward_int all -- anywhere anywhere
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-FWD-ILL-ROUTING '
DROP all -- anywhere anywhere
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
LOG icmp -- anywhere anywhere limit: avg 3/min burst 5 icmp time-exceeded LOG level warning tcp-options ip-options prefix `SFW2-OUT-TRACERT-ATTEMPT '
ACCEPT icmp -- anywhere anywhere icmp time-exceeded
ACCEPT icmp -- anywhere anywhere icmp port-unreachable
ACCEPT icmp -- anywhere anywhere icmp fragmentation-needed
ACCEPT icmp -- anywhere anywhere icmp network-prohibited
ACCEPT icmp -- anywhere anywhere icmp host-prohibited
ACCEPT icmp -- anywhere anywhere icmp communication-prohibited
DROP icmp -- anywhere anywhere icmp destination-unreachable
ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-OUT-ERROR '
Chain forward_dmz (0 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 5 state INVALID LOG level warning tcp-options ip-options prefix `SFW2-FWDdmz-DROP-DEFLT-INV '
DROP all -- anywhere anywhere state INVALID
ACCEPT icmp -- anywhere anywhere state RELATED icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp echo-reply
ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-FWDdmz-DROP-DEFLT '
DROP all -- anywhere anywhere
Chain forward_ext (1 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 5 state INVALID LOG level warning tcp-options ip-options prefix `SFW2-FWDext-DROP-DEFLT-INV '
DROP all -- anywhere anywhere state INVALID
ACCEPT icmp -- anywhere anywhere state RELATED icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp echo-reply
ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-FWDext-DROP-DEFLT '
DROP all -- anywhere anywhere
Chain forward_int (1 references)
target prot opt source destination
LOG all -- anywhere anywhere limit: avg 3/min burst 5 state INVALID LOG level warning tcp-options ip-options prefix `SFW2-FWDint-DROP-DEFLT-INV '
DROP all -- anywhere anywhere state INVALID
ACCEPT icmp -- anywhere anywhere state RELATED icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp echo-reply
ACCEPT all -- anywhere anywhere state NEW,RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-FWDint-DROP-DEFLT '
DROP all -- anywhere anywhere
Chain input_dmz (0 references)
target prot opt source destination
LOG all -- anywhere anywhere PKTTYPE = broadcast limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-DROP-BCASTd '
DROP all -- anywhere anywhere PKTTYPE = broadcast
ACCEPT icmp -- anywhere anywhere icmp source-quench
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp echo-reply
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp time-exceeded
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp parameter-problem
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp timestamp-reply
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp address-mask-reply
LOG all -- anywhere anywhere limit: avg 3/min burst 5 state INVALID LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP-DEFLT-INV '
DROP all -- anywhere anywhere state INVALID
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ssh flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:sunrpc flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:sunrpc flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ipp flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ipp flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:827 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:827 flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:nfs flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:nfs flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:16273 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:16273 flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ssh flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ssh flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:sunrpc flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:sunrpc flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:sunrpc flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:sunrpc flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ipp flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ipp flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ipp flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ipp flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:827 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:827 flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:827 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:827 flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:nfs flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:nfs flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:nfs flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:nfs flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:16273 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:16273 flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:16273 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP '
DROP tcp -- anywhere anywhere tcp dpt:16273 flags:SYN,RST,ACK/SYN
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-INdmz-DROP-DEFLT '
DROP all -- anywhere anywhere
Chain input_ext (1 references)
target prot opt source destination
LOG all -- anywhere anywhere PKTTYPE = broadcast limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-DROP-BCASTe '
DROP all -- anywhere anywhere PKTTYPE = broadcast
ACCEPT icmp -- anywhere anywhere icmp source-quench
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp echo-reply
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp time-exceeded
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp parameter-problem
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp timestamp-reply
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp address-mask-reply
LOG all -- anywhere anywhere limit: avg 3/min burst 5 state INVALID LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP-DEFLT-INV '
DROP all -- anywhere anywhere state INVALID
LOG tcp -- anywhere anywhere tcp dpt:ident state NEW limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-INext-REJECT '
reject_func tcp -- anywhere anywhere tcp dpt:ident state NEW
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ssh flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:sunrpc flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:sunrpc flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ipp flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ipp flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:827 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:827 flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:nfs flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:nfs flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:16273 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:16273 flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ssh flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ssh flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:sunrpc flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:sunrpc flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:sunrpc flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:sunrpc flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ipp flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ipp flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:ipp flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:ipp flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:827 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:827 flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:827 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:827 flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:nfs flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:nfs flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:nfs flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:nfs flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:16273 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:16273 flags:SYN,RST,ACK/SYN
LOG tcp -- anywhere anywhere limit: avg 3/min burst 5 tcp dpt:16273 flags:SYN,RST,ACK/SYN LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP '
DROP tcp -- anywhere anywhere tcp dpt:16273 flags:SYN,RST,ACK/SYN
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-INext-DROP-DEFLT '
DROP all -- anywhere anywhere
Chain input_int (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp source-quench
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp echo-reply
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp destination-unreachable
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp time-exceeded
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp parameter-problem
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp timestamp-reply
ACCEPT icmp -- anywhere anywhere state RELATED,ESTABLISHED icmp address-mask-reply
LOG all -- anywhere anywhere limit: avg 3/min burst 5 state INVALID LOG level warning tcp-options ip-options prefix `SFW2-INint-DROP-DEFLT-INV '
DROP all -- anywhere anywhere state INVALID
LOG all -- anywhere anywhere limit: avg 3/min burst 5 LOG level warning tcp-options ip-options prefix `SFW2-INint-DROP-DEFLT '
DROP all -- anywhere anywhere
Chain reject_func (1 references)
target prot opt source destination
REJECT tcp -- anywhere anywhere reject-with tcp-reset
REJECT udp -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-proto-unreachable
^ permalink raw reply
* wireless geo stuff (was Re: wireless-2.6 status (25 January 2006))
From: Jeff Garzik @ 2006-01-27 2:15 UTC (permalink / raw)
To: Simon Barber
Cc: Michael Buesch, Ben Greear, David Hollis, John W. Linville,
Samuel Ortiz, netdev, Linux Kernel, Alan Cox
In-Reply-To: <C86180A8C204554D8A3323D8F6B0A29FEB471D@dhost002-46.dex002.intermedia.net>
Simon Barber wrote:
> In order to get FCC certification the manufacturer must ensure there is
> no easy way for the user to tune to illegal frequencies. Broadcom has
> done their job - it was not easy to reverse engineer their driver. Now
> the cat is out of the bag. The open source driver is not illegal -
> although it may be illegal to use it - since the chipset and driver were
> likely certified together. I'm no expert in FCC regulation, so take all
> of this with a pinch of salt.
First, kernel developers should do the best they can to provide
facilities to limit the frequencies, including sane and safe defaults
for the softmac cases. It just makes sense to do that, from a "friendly
neighbor" and "don't operate out of spec" perspective, if nothing else.
It's damned _rude_ to use channels other than the ones selected by the
Responsible Authority. Some ham radio operator -- like me -- might be
using that frequency to carry on a pleasant Morse code conversation with
someone else halfway across the world. Linux software shalt not be
rude. :)
Second, if someone takes steps to disable these safeguards we build in,
that's akin to putting illegal crystals into a radio, or tuning a
transmitter to police/emergency bands.
Finally, binary-only software is clearly _not_ a barrier to this sort of
circumvention. Reverse engineering x86 software is a skill that's very
widespread, relative to other sorts of reverse engineering. Reverse
engineering tools for the x86 are very mature these days, having had two
decades to grow and flourish. If the _hardware_ can be programmed
maliciously, there's not a whole lot you can do about it... particularly
when the hardware manufacturer chooses a method of obfuscation (x86
code) practically designed for easy analysis.
Jeff
^ permalink raw reply
* [7/10] remove ISA legacy functions: drivers/net/lance.c
From: Adrian Bunk @ 2006-01-26 22:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: Al Viro, linux-kernel, jgarzik, netdev
In-Reply-To: <20060126223126.GD3668@stusta.de>
From: Al Viro <viro@zeniv.linux.org.uk>
switch to ioremap()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/lance.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
aadde842b4976445ac101c6ed04986382988d035
diff --git a/drivers/net/lance.c b/drivers/net/lance.c
--- a/drivers/net/lance.c
+++ b/drivers/net/lance.c
@@ -464,20 +464,25 @@ static int __init lance_probe1(struct ne
static int did_version; /* Already printed version info. */
unsigned long flags;
int err = -ENOMEM;
+ void __iomem *bios;
/* First we look for special cases.
Check for HP's on-board ethernet by looking for 'HP' in the BIOS.
There are two HP versions, check the BIOS for the configuration port.
This method provided by L. Julliard, Laurent_Julliard@grenoble.hp.com.
*/
- if (isa_readw(0x000f0102) == 0x5048) {
+ bios = ioremap(0xf00f0, 0x14);
+ if (!bios)
+ return -ENOMEM;
+ if (readw(bios + 0x12) == 0x5048) {
static const short ioaddr_table[] = { 0x300, 0x320, 0x340, 0x360};
- int hp_port = (isa_readl(0x000f00f1) & 1) ? 0x499 : 0x99;
+ int hp_port = (readl(bios + 1) & 1) ? 0x499 : 0x99;
/* We can have boards other than the built-in! Verify this is on-board. */
if ((inb(hp_port) & 0xc0) == 0x80
&& ioaddr_table[inb(hp_port) & 3] == ioaddr)
hp_builtin = hp_port;
}
+ iounmap(bios);
/* We also recognize the HP Vectra on-board here, but check below. */
hpJ2405A = (inb(ioaddr) == 0x08 && inb(ioaddr+1) == 0x00
&& inb(ioaddr+2) == 0x09);
^ permalink raw reply
* [6/10] remove ISA legacy functions: drivers/net/hp100.c
From: Adrian Bunk @ 2006-01-26 22:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Al Viro, linux-kernel, perex, jgarzik, netdev
In-Reply-To: <20060126223126.GD3668@stusta.de>
From: Al Viro <viro@zeniv.linux.org.uk>
hp100 has ->mem_ptr_virt set for all memory-mapped cases; removed
rudiment of old version that used ioremap() only when physical
address wasn't an ISA one. These days it's simply a dead code.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/net/hp100.c | 30 ++++++++----------------------
1 files changed, 8 insertions(+), 22 deletions(-)
c9a2c709fa782a0dd7b1bbb0160b325e446ae523
diff --git a/drivers/net/hp100.c b/drivers/net/hp100.c
--- a/drivers/net/hp100.c
+++ b/drivers/net/hp100.c
@@ -1718,17 +1718,10 @@ static int hp100_start_xmit(struct sk_bu
hp100_outw(i, FRAGMENT_LEN); /* and first/only fragment length */
if (lp->mode == 2) { /* memory mapped */
- if (lp->mem_ptr_virt) { /* high pci memory was remapped */
- /* Note: The J2585B needs alignment to 32bits here! */
- memcpy_toio(lp->mem_ptr_virt, skb->data, (skb->len + 3) & ~3);
- if (!ok_flag)
- memset_io(lp->mem_ptr_virt, 0, HP100_MIN_PACKET_SIZE - skb->len);
- } else {
- /* Note: The J2585B needs alignment to 32bits here! */
- isa_memcpy_toio(lp->mem_ptr_phys, skb->data, (skb->len + 3) & ~3);
- if (!ok_flag)
- isa_memset_io(lp->mem_ptr_phys, 0, HP100_MIN_PACKET_SIZE - skb->len);
- }
+ /* Note: The J2585B needs alignment to 32bits here! */
+ memcpy_toio(lp->mem_ptr_virt, skb->data, (skb->len + 3) & ~3);
+ if (!ok_flag)
+ memset_io(lp->mem_ptr_virt, 0, HP100_MIN_PACKET_SIZE - skb->len);
} else { /* programmed i/o */
outsl(ioaddr + HP100_REG_DATA32, skb->data,
(skb->len + 3) >> 2);
@@ -1798,10 +1791,7 @@ static void hp100_rx(struct net_device *
/* First we get the header, which contains information about the */
/* actual length of the received packet. */
if (lp->mode == 2) { /* memory mapped mode */
- if (lp->mem_ptr_virt) /* if memory was remapped */
- header = readl(lp->mem_ptr_virt);
- else
- header = isa_readl(lp->mem_ptr_phys);
+ header = readl(lp->mem_ptr_virt);
} else /* programmed i/o */
header = hp100_inl(DATA32);
@@ -1833,13 +1823,9 @@ static void hp100_rx(struct net_device *
ptr = skb->data;
/* Now transfer the data from the card into that area */
- if (lp->mode == 2) {
- if (lp->mem_ptr_virt)
- memcpy_fromio(ptr, lp->mem_ptr_virt,pkt_len);
- /* Note alignment to 32bit transfers */
- else
- isa_memcpy_fromio(ptr, lp->mem_ptr_phys, pkt_len);
- } else /* io mapped */
+ if (lp->mode == 2)
+ memcpy_fromio(ptr, lp->mem_ptr_virt,pkt_len);
+ else /* io mapped */
insl(ioaddr + HP100_REG_DATA32, ptr, pkt_len >> 2);
skb->protocol = eth_type_trans(skb, dev);
^ 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