I just did a very quick glance over the tree. Some extremly highlevel
comments to start with before actually starting the source review:
- why do you need your own libcrc? lib/crc32.c has a crc32_le
- libsa should go. Much of it is just wrappers of kernel functions
that should be used dir
Hi Patrick,
> >>> +struct tc_psp_qopt
> >>> +{
> >>> + __u32 defcls;
> >>> + __u32 rate;
> >>> +};
> >>
> >> What unit is rate measured in?
> >>
> > 'rate' is the transmission rate in bytes per sec.
>
>
> So wouldn't it make sense to use u64 then for 10GBit networks?
>
I decided to use u32
On Tue, 27 Nov 2007 20:45:36 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
> drivers/net/r6040.c: In function 'rx_buf_alloc':
> drivers/net/r6040.c:262: warning: passing argument 2 of 'pci_map_single'
> makes pointer from integer without a cast
> drivers/net/r6040.c: In function 'r6040_up':
> dr
On Tue, 2007-11-27 at 22:09 -0800, Stephen Hemminger wrote:
> ERROR: Macros with multiple statements should be enclosed in a do - while loop
> #21846: FILE: drivers/net/sfc/net_driver.h:1096:
> + for (_channel = &_efx->channel[0]; \
> + _channel < &_efx->ch
On Fri, 23 Nov 2007 17:08:15 +
Ben Hutchings <[EMAIL PROTECTED]> wrote:
> This is a net driver (and MTD driver, sfc_mtd) for our SFC4000 10G
> Ethernet controller, branded "Solarstorm", with various PHYs. It is
> intended to support our NIC reference designs SFE4001 (10GBASE-T),
> SFE4002 (XF
drivers/net/r6040.c: In function 'rx_buf_alloc':
drivers/net/r6040.c:262: warning: passing argument 2 of 'pci_map_single' makes
pointer from integer without a cast
drivers/net/r6040.c: In function 'r6040_up':
drivers/net/r6040.c:631: warning: cast from pointer to integer of different size
drivers/
On 11/27/07 7:27 PM, "Rusty Russell" <[EMAIL PROTECTED]> wrote:
> On Tuesday 27 November 2007 16:35:42 Tom Tucker wrote:
>> On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
>> Explicitly documenting what comprises the kernel API (external,
>> supported) and what comprises the kernel imple
On Wed, 28 Nov 2007 01:49:54 +0100 =?utf-8?q?Ferenc_W=C3=A1gner?= wrote:
> Also remove trailing spaces from multivalued files.
>
> This fixes output like for example:
>
> $ od -c /sys/class/net/bond0/bonding/slaves
> 000 e t h - l e f t e t h - r i g
> 0
Stephen Hemminger wrote:
Is there any standard kernel config define for "this platform can't do
unaligned accesses"?
Not that I know of, but there should be.
To be somewhat more complexicated, some platforms (e.g. MIPS) can do
unaligned references quite cheaply, but they need different opco
On Tuesday 27 November 2007 21:50:16 Andi Kleen wrote:
> Goals are:
> - Limit the interfaces available for out of tree modules to reasonably
> stable ones that are already used by a larger set of drivers.
Not the goals. I haven't seen the *problem* yet.
> - Limit size of exported API to make sta
On Tuesday 27 November 2007 16:35:42 Tom Tucker wrote:
> On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> Explicitly documenting what comprises the kernel API (external,
> supported) and what comprises the kernel implementation (internal, not
> supported).
But the former is currently an e
Dear Auke and e1000 maintainers
Hi, this is the patch which makes the e1000 driver legacy I/O port free.
I've received some advice from Auke quite long time ago, and submitted
a patch (http://lkml.org/lkml/2007/8/10/11) which I think meets what Auke
had told me. Since the patch has not received a
Adrian Bunk wrote:
On Tue, Nov 27, 2007 at 01:15:23PM -0800, Rick Jones wrote:
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling of
Herbert,
Monday 26 November 2007 20:07, Herbert Xu wrote:
> On Mon, Nov 26, 2007 at 11:18:45AM +0800, Herbert Xu wrote:
> >
> > I'm just going to revert this patch for 2.6.24 since we've lived
> > with this race for so long anyway.
>
> Actually, instead of reverting it completely I'm just going t
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Tue, 27 Nov 2007 10:56:43 +0100 Ferenc Wagner <[EMAIL PROTECTED]> wrote:
>
>>> - raise patches against the latest Linus tree
>>> (ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/)
>>
>> I thought it was better to change to git. Isn't it so?
>>
Code for rendering multivalue sysfs files occurs three times
in this module. Rename 'buffer' to 'buf' in the first, for
the sake of consistency.
Signed-off-by: Ferenc Wágner <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_sysfs.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-
The previous code returned '\n' (that is, a single empty line)
from most files, with one exception (xmit_hash_policy), where
it returned 'NA\n'. This patch consolidates each file to return
nothing at all if not applicable, not even a '\n'.
I find this behaviour more usual, more useful, more effic
Also remove trailing spaces from multivalued files.
This fixes output like for example:
$ od -c /sys/class/net/bond0/bonding/slaves
000 e t h - l e f t e t h - r i g
020 h t \n \0
025
It mostly entails deleting '+1'-s after sprintf() calls:
> >> Which ones were they exactly? I think JamesB wanted only common
> >> transport values in the transport class. If it is driver specific then
> >> it should go on the host or target or device with the scsi_host_template
> >> attrs.
> >>
> >
> > It's a chicken & egg issue to put "port mapper
Stephen Hemminger wrote:
> On Tue, 27 Nov 2007 14:34:44 -0800
> "Kok, Auke" <[EMAIL PROTECTED]> wrote:
>
>> Stephen Hemminger wrote:
>>> On Tue, 27 Nov 2007 19:52:24 +0100
>>> Robert Olsson <[EMAIL PROTECTED]> wrote:
>>>
Hello!
I've discovered a bug while testing the new multiQ NAPI
Don't exit polling when we have not yet used our budget, this causes
the NAPI system to end up with a messed up poll list.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1
On Mon, 2007-11-26 at 21:02 +0100, Johannes Berg wrote:
> sungem's gem_reset_task() will unconditionally try to disable NAPI even
> when it's called while the interface is not operating and hence the NAPI
> struct isn't enabled. Make napi_disable() depend on gp->running.
>
> Also removes a superf
On Tue, Nov 27, 2007 at 03:00:22PM -0800, Stephen Hemminger wrote:
> On Tue, 27 Nov 2007 23:37:43 +0100
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > > With my "Enterprise" hat on, I can see where Andi was coming from
> > > originally.
> >
> > For the record my original motivation was to fix the
On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> On Monday 26 November 2007 17:15:44 Roland Dreier wrote:
> > It seems pretty
> > clear to me that having a mechanism that requires modules to make
> > explicit which (semi-)internal APIs makes reviewing easier
>
> Perhaps you've got lot
On Tue, 27 Nov 2007 23:37:43 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > With my "Enterprise" hat on, I can see where Andi was coming from
> > originally.
>
> For the record my original motivation was to fix the "TCP exports everything
> for ipv6.ko" case cleanly. I later realized that it wo
On Tue, 27 Nov 2007 22:09:42 +0100, Adrian Bunk said:
> Are there common reasons why these drivers are not upstream?
Well, on my laptop, I'm currently dragging along 3 out-of-tree kernel modules.
2 are well-known binary blobs so it's between me and the vendor, as usual.
The third is a USB webcam
On Tue, 27 Nov 2007 14:34:44 -0800
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > On Tue, 27 Nov 2007 19:52:24 +0100
> > Robert Olsson <[EMAIL PROTECTED]> wrote:
> >
> >> Hello!
> >>
> >> I've discovered a bug while testing the new multiQ NAPI code. In hi-load
> >> situati
> With my "Enterprise" hat on, I can see where Andi was coming from
> originally.
For the record my original motivation was to fix the "TCP exports everything
for ipv6.ko" case cleanly. I later realized that it would be useful for the
ABI stability issues too, but it was really not my primary mot
Stephen Hemminger wrote:
> On Tue, 27 Nov 2007 19:52:24 +0100
> Robert Olsson <[EMAIL PROTECTED]> wrote:
>
>> Hello!
>>
>> I've discovered a bug while testing the new multiQ NAPI code. In hi-load
>> situations when we take down an interface we get a kernel panic. The
>> oops is below.
>>
>> From
Using PCIE advanced error recovery stuff creates more user problems than it's
worth.
The AER stuff depends on MMCONFIG and in many configurations it just doesn't
work.
Plus it doesn't add any real functionality to the driver. The sky2
driver handles its own errors fine as is.
This reverts 555382
Using the hardware window into PCI config space is more reliable
and smaller/faster than using the pci_config routines. It avoids issues
with MMCONFIG etc.
Reverts: 167f53d05fccb47b6eeadac7f6705b3f2f042d03
Please apply for 2.6.24
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/driver
Add workaround for issues FE+ (A0) transmit watermark.
This is copied verbatim from vendor driver sk98lin (10.22.4.3).
Don't have that chip version and no more information seems to be available.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-11-26 14:02:
On Tue, 27 Nov 2007 19:52:24 +0100
Robert Olsson <[EMAIL PROTECTED]> wrote:
>
> Hello!
>
> I've discovered a bug while testing the new multiQ NAPI code. In hi-load
> situations when we take down an interface we get a kernel panic. The
> oops is below.
>
> From what I see this happens when driv
On Tue, 27 Nov 2007 13:34:57 PST, Michael Chan said:
> Ideally, the BIOS should modify the NVRAM's setting when it is changed.
> We will talk to Dell to get their opinion on this as this is very
> confusing to the user.
That would certainly explain what I'm seeing, and I can certainly wait
if the
On Tue, Nov 27, 2007 at 01:15:23PM -0800, Rick Jones wrote:
>> The real problem is that these drivers are not in the upstream kernel.
>>
>> Are there common reasons why these drivers are not upstream?
>
> One might be that upstream has not accepted them. Anything doing or
> smelling of TOE comes
From: Divy Le Ray <[EMAIL PROTECTED]>
Fix MAC stats accounting.
Fix get_stats.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/chelsio/cxgb2.c | 67 +++--
drivers/net/chelsio/pm3393.c | 112 +-
drivers/net/chelsio/s
From: Divy Le Ray <[EMAIL PROTECTED]>
The patch ensures that a GSO skb has enough headroom
to push an encapsulating cpl_tx_pkt_lso header.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/chelsio/cxgb2.c |3 ++-
drivers/net/chelsio/sge.c | 34 +++---
From: Divy Le Ray <[EMAIL PROTECTED]>
netif_rx_complete() should be called only
when work_done < budget.
Signed-off-by: Divy Le ray <[EMAIL PROTECTED]>
---
drivers/net/chelsio/sge.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/chelsio/sge.c b/driver
Jeff,
I'm submitting a patch series for inclusion in 2.6.24 for the cxgb driver.
The patches are built against Linus'git tree.
Here is a brief description:
- Ensure that GSO skbs have enough headroom before encapsulating them,
- Fix a crash in NAPI mode,
- Fix statistics accounting and report.
On Tue, Nov 27, 2007 at 10:09:42PM +0100, Adrian Bunk wrote:
> On Tue, Nov 27, 2007 at 02:00:37PM -0500, Dave Jones wrote:
> > On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote:
> >
> > > 1) Why is everyone so concerned that export symbol space is large?
> > > - doe
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling of TOE comes to mind right away.
rick jones
-
To unsubscribe from this list: send
On Tue, Nov 27, 2007 at 02:00:37PM -0500, Dave Jones wrote:
> On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote:
>
> > 1) Why is everyone so concerned that export symbol space is large?
> >- does it cost cpu or running memory?
> >- does it cause bugs?
> >- or are y
On Tue, 2007-11-27 at 01:35 -0800, [EMAIL PROTECTED] wrote:
>
> Issue:
>
> I (for unrelated reasons) run powertop, and it suggests I conserve power
> by doing 'ethtool -s eth0 wol d'. I look at it, and think that it's daft,
> because (a) the Dell factory default is WOL disabled and (b) if it wa
On Tue, 27 Nov 2007 15:12:42 +0100, Andi Kleen said:
> > OK, short of making IPv4 a module (which would be a worthy task :)
>
> At some point there were patches, it is probably not very difficult.
> But DaveM resisted at some point because he didn't want people
> to replace the network stack (alth
On Tue, 27 Nov 2007 08:04:28 PST, Michael Chan said:
> [EMAIL PROTECTED] wrote:
>
> > (a) the Dell factory default is WOL disabled and (b)
> > if it wasn't
> > the default, I'd have *set* it to disabled, and (c) I even
> > went back and
> > rebooted and checked the BIOS setting - disabled. Nonethe
Hello!
I've discovered a bug while testing the new multiQ NAPI code. In hi-load
situations when we take down an interface we get a kernel panic. The
oops is below.
>From what I see this happens when driver does napi_disable() and clears
NAPI_STATE_SCHED. In net_rx_action there is a check for wo
On Mon, Nov 26, 2007 at 10:25:33AM -0800, Stephen Hemminger wrote:
> 1) Why is everyone so concerned that export symbol space is large?
> - does it cost cpu or running memory?
> - does it cause bugs?
> - or are you just worried about "evil modules"?
To clarify something here,
On Tue, Nov 27, 2007 at 11:45:37AM -0600, Tom Tucker wrote:
>
> On Tue, 2007-11-27 at 18:15 +0100, Adrian Bunk wrote:
> > On Mon, Nov 26, 2007 at 11:35:42PM -0600, Tom Tucker wrote:
> > > On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> > >...
> > > > No. That's the wrong question. What
Hello Linux Community,
I'd like to introduce a new Open Source project named Open-FCoE.
FCoE is the acronym for Fibre Channel over Ethernet, which is the
encapsulation of Fibre Channel frames within Ethernet packets. FCoE will
allow systems with an Ethernet adapter and a Fibre Channel Forwarde
On Tue, 27 Nov 2007 09:16:07 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > Herbert Xu wrote:
> >> On Sat, Nov 24, 2007 at 02:49:36PM +0100, Johannes Berg wrote:
> >>
> >>> Right. I just didn't think that would be a valid value for an
> >>> architecture to set.
Lukas Hejtmanek wrote:
> On Tue, Nov 27, 2007 at 09:40:08AM -0800, Kok, Auke wrote:
>>> I'm afraid, I'm missing the point as you have stated that in-kernel drivers
>>> have problem with suspicious board hang...
>> my mistake, sorry for that confusion.
>>
>> the fake hangs on 82562/6 devices occur o
On Tue, Nov 27, 2007 at 09:40:08AM -0800, Kok, Auke wrote:
> > I'm afraid, I'm missing the point as you have stated that in-kernel drivers
> > have problem with suspicious board hang...
>
> my mistake, sorry for that confusion.
>
> the fake hangs on 82562/6 devices occur on 10mbit link only. You
On Tue, 2007-11-27 at 18:15 +0100, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 11:35:42PM -0600, Tom Tucker wrote:
> > On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> >...
> > > No. That's the wrong question. What's the real upside?
> >
> > Explicitly documenting what comprises the k
[moving this discussion to netdev, dropping lkml]
Lukas Hejtmanek wrote:
> On Tue, Nov 27, 2007 at 08:48:52AM -0800, Kok, Auke wrote:
>>> unfortunately, the 7.6.9 driver cannot be compiled with 2.6.24-rc3-git2
>>> kernel due to compilation errors.
>> but the in-kernel version of e1000 supports th
On Tue, Nov 27, 2007 at 10:02:22AM +0100, Andi Kleen wrote:
>...
> That is EXPORT_SYMBOL already. The trouble is just that it covers
> too much. My patchkit is trying to limit it again for a specific
> use case -- exporting an "internal" interface to another module.
> Or rather a set of modules.
>
Stephen Hemminger wrote:
Herbert Xu wrote:
On Sat, Nov 24, 2007 at 02:49:36PM +0100, Johannes Berg wrote:
Right. I just didn't think that would be a valid value for an
architecture to set.
OK. Let me clarify this a bit more. We require at least one
of the following rules to be met:
Herbert Xu wrote:
Luckily all sky2 users have been on x86 so far :)
Hardly so. My previous employer was MIPS and we used it there (with my
patch.)
-hpa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Mon, Nov 26, 2007 at 11:35:42PM -0600, Tom Tucker wrote:
> On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
>...
> > No. That's the wrong question. What's the real upside?
>
> Explicitly documenting what comprises the kernel API (external,
> supported) and what comprises the kernel imp
> -Original Message-
> From: YOSHIFUJI Hideaki / 吉藤英明 [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 26, 2007 10:01 AM
> To: [EMAIL PROTECTED]
> Cc: Templin, Fred L; netdev@vger.kernel.org;
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [PATCH 01/01] ip
> One more thing: your qdisc can only be used as root qdisc since it
> produces packets itself and thereby violates the rule that a qdisc
> can only hand out packets that were previously enqueued to it.
> Using it as a leaf qdisc can make the upper qdiscs qlen counter
> go negative, causing infinit
On Tue, Nov 27, 2007 at 08:43:24AM -0700, Jonathan Corbet wrote:
> Might the recent discussion on the exporting of sys_open() and
> sys_read() be an example here? There would appear to be a consensus
> that people should not have used those functions, but they are now
> proving difficult to unexpo
On Sat, Nov 24, 2007 at 01:29:19PM +0100, Thomas Bogendoerfer wrote:
> Following patch is clearly 2.6.25 material and is needed to get SGI IP28
> machines supported.
>
> Thomas.
>
> SGI IP28 machines would need special treatment (enable adding addtional
> wait states) when accessing memory uncac
This hook is protected with the RCU, so simple
if (br_should_route_hook)
br_should_route_hook(...)
is not enough on some architectures.
Use the rcu_dereference/rcu_assign_pointer in this case.
Fixed Stephen's comment concerning using the typeof().
Signed-off-by: Pavel E
On Tue, 27 Nov 2007 17:39:42 +0300
Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> In case the br_netfilter_init() (or any subsequent call)
> fails, the br_fdb_fini() must be called to free the allocated
> in br_fdb_init() br_fdb_cache kmem cache.
>
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTE
On Tue, 27 Nov 2007 19:12:11 +0300
Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> This hook is protected with the RCU, so simple
>
> if (br_should_route_hook)
> br_should_route_hook(...)
>
> is not enough on some architectures.
>
> Use the rcu_dereference/rcu_assign_pointer in
This hook is protected with the RCU, so simple
if (br_should_route_hook)
br_should_route_hook(...)
is not enough on some architectures.
Use the rcu_dereference/rcu_assign_pointer in this case.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/brid
[EMAIL PROTECTED] wrote:
> (a) the Dell factory default is WOL disabled and (b)
> if it wasn't
> the default, I'd have *set* it to disabled, and (c) I even
> went back and
> rebooted and checked the BIOS setting - disabled. Nonetheless:
>
> # ethtool eth0 | grep Wake
> Supports Wake-on:
On Tue, Nov 27, 2007 at 08:43:24AM -0700, Jonathan Corbet wrote:
> Rusty said:
>
> > Well, introduce an EXPORT_SYMBOL_INTERNAL(). It's a lot less code. But
> > you'd
> > still need to show that people are having trouble knowing what APIs to use.
>
> Might the recent discussion on the exportin
Rusty said:
> Well, introduce an EXPORT_SYMBOL_INTERNAL(). It's a lot less code. But
> you'd
> still need to show that people are having trouble knowing what APIs to use.
Might the recent discussion on the exporting of sys_open() and
sys_read() be an example here? There would appear to be a
> > > Not needed because the bridge is already handling it:
> > >
> > > 1) If running STP (ie true bridge), then all link local multicast is only
> > > received by
> > > the bridge and never forwarded.
> >
> > Well, typical access point setups bridge the wireless AP interface with
> > wired, EAPO
On Nov 27, 2007 8:24 AM, Johannes Berg <[EMAIL PROTECTED]> wrote:
>
> > > + if (unlikely(skb->protocol = htons(ETH_P_PAE)))
> > > + goto drop;
> > > +
> > > switch (p->state) {
> > > case BR_STATE_FORWARDING:
> >
> > Not needed because the bridge is already handling it:
> >
> >
On Tue, Nov 27, 2007 at 03:12:42PM +0100, Andi Kleen wrote:
>
> For Networking: e.g. symbols i put into inet, which are only
> used by protocols (sctp, dccp, udplite, ipv6)
Wait, that's exactly Rusty's point (I think :)
These symbols are exported because they're needed by protocols.
If they weren
The inet_lro.c:lro_gen_skb() function fails to include
NET_IP_ALIGN padding at the front of the sk_buffs it creates,
leading to alignment warnings on architectures which require
strict alignment (seen on sparc64). The attached patch
adds NET_IP_ALIGN padding.
Signed off by: Andrew Gallatin <[EMA
In message <[EMAIL PROTECTED]>,"Rober
t P. J. Day" writes:
>> > in any event, i just thought i'd point it out. if you're absolutely
>> > sure there will never be another call to setup_dev() from somewhere
>> > else, then, yes, it's safe.
>>
>> I understood your opinions. and partially agree with y
In case the br_netfilter_init() (or any subsequent call)
fails, the br_fdb_fini() must be called to free the allocated
in br_fdb_init() br_fdb_cache kmem cache.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/bridge/br.c b/net/bridge/br.c
index 93867bb..a901828 100644
--
> OK, short of making IPv4 a module (which would be a worthy task :)
At some point there were patches, it is probably not very difficult.
But DaveM resisted at some point because he didn't want people
to replace the network stack (although I personally don't have a problem
with that)
> do you hav
On Tue, Nov 27, 2007 at 05:00:55AM -0800, Joerg Pommnitz wrote:
...
> The OLSR traffic was obviously generated locally (not forwarded).
> You claim, that the TOS value for locally generated traffic does
> not influence its priority?
I wouldn't say "I claim": I've found something like this 'long ti
On Tue, 2007-11-27 at 16:59 +0300, Anton Vorontsov wrote:
> On Tue, Nov 27, 2007 at 02:17:11PM +0100, Joakim Tjernlund wrote:
> >
> > On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote:
> > > On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote:
> > > > On Mon, 2007-11-26 at 17:
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 27, 2007 at 03:26:52PM +1100, Rusty Russell wrote:
>> On Monday 26 November 2007 16:58:08 Roland Dreier wrote:
>> > > > I agree that we shouldn't make things too hard for out-of-tree
>> > > > modules, but I disagree with your first statement: th
I just wanted to ask whether there is a general interest in this patch.
If yes: great, how to proceed?
otherwise: please let me know why.
Thanks!
Ariane Keller wrote:
Hi Stephen
Approximately a year ago we discussed an enhancement to netem,
which we called "trace control for netem".
We obt
On Tue, Nov 27, 2007 at 02:17:11PM +0100, Joakim Tjernlund wrote:
>
> On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote:
> > On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote:
> > > On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> > > > fixed-link says: register new
> > + if (unlikely(skb->protocol = htons(ETH_P_PAE)))
> > + goto drop;
> > +
> > switch (p->state) {
> > case BR_STATE_FORWARDING:
>
> Not needed because the bridge is already handling it:
>
> 1) If running STP (ie true bridge), then all link local multicast is only
> receiv
Joerg Pommnitz wrote:
Great :-(. I went over the ChangeLogs for later kernel versions, but
couldn't find anything.
I'll try to come up with a working .config for the most current kernel
that works on my hardware and test again.
Do you have a pointer to the fix so that I could try to patch a 2.6
On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote:
> On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote:
> > On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> > > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> > > not connected to the real MDIO bus
Laszlo Attila Toth wrote:
Interface group values can be checked on both input and output interfaces.
Needs a minor update to comply with the naming scheme Jan introduced,
but I can take care of that once the other patches are merged.
-
To unsubscribe from this list: send the line "unsubscribe
The following race is possible when one cpu unregisters the handler
while other one is trying to receive a message and call this one:
CPU1: CPU2:
inet_diag_rcv() inet_diag_unregister()
mutex_lock(&inet_diag_mut
Laszlo Attila Toth wrote:
Interface groups let handle different interfaces together.
Modified net device structure and netlink interface.
Looks good.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
Great :-(. I went over the ChangeLogs for later kernel versions, but
couldn't find anything.
I'll try to come up with a working .config for the most current kernel
that works on my hardware and test again.
Do you have a pointer to the fix so that I could try to patch a 2.6.20
kernel?
--
Regar
Laszlo Attila Toth wrote:
In do_setlink the device changes don't need to be protected. Notification
is sent at the end of the function once if any modification occured
and once if an address has been changed.
Signed-off-by: Laszlo Attila Toth <[EMAIL PROTECTED]>
---
net/core/rtnetlink.c | 32
sungem's gem_reset_task() will unconditionally try to disable NAPI even
when it's called while the interface is not operating and hence the NAPI
struct isn't enabled. Make napi_disable() depend on gp->running.
Also removes a superfluous test of gp->running in the same function.
Signed-off-by: Joh
> So, are you still sure you've tested such a case?
Well, the problem that triggered my investigation was
that the OLSR daemon (www.olsr.org) calculates the quality
of a link according to the packet loss for LQ HELLO packets
(UDP broadcast packets). To prevent other traffic from
interfering with t
Joerg Pommnitz wrote:
> It works fine here, I'm guessing that Jörg is using an old kernel
> version that had a bug in prio classification without filters.
This is 2.6.20.21, from 17-Oct-2007.
Yes, that version is broken. I think it was fixed in 2.6.22 or 2.6.23.
-
To unsubscribe from this
> It works fine here, I'm guessing that Jörg is using an old kernel
> version that had a bug in prio classification without filters.
This is 2.6.20.21, from 17-Oct-2007.
--
Regards
Joerg
__ Ihre erste Baustelle? Wissenswertes
für Bastler
Pavel Emelyanov <[EMAIL PROTECTED]> writes:
> [snip]
>
>>
>> Well I clearly goofed when I added the initial network namespace support
>> for /proc/net. Currently things work but there are odd details visible
>> to user space, even when we have a single network namespace.
>>
>> Since we do not c
Jarek Poplawski wrote:
On Tue, Nov 27, 2007 at 02:54:10AM -0800, Joerg Pommnitz wrote:
Jarek,
this is all about outgoing packets, e.g. egress to use your word.
It doesn't matter whether the packets are originated locally or
whether the packets are forwarded from another host (I tried
both).
To
TAKANO Ryousei wrote:
Hi Patrick,
+struct tc_psp_qopt
+{
+ __u32 defcls;
+ __u32 rate;
+};
What unit is rate measured in?
'rate' is the transmission rate in bytes per sec.
So wouldn't it make sense to use u64 then for 10GBit networks?
+ skb_put(skb, size);
This i
On Tue, Nov 27, 2007 at 02:54:10AM -0800, Joerg Pommnitz wrote:
> Jarek,
> this is all about outgoing packets, e.g. egress to use your word.
> It doesn't matter whether the packets are originated locally or
> whether the packets are forwarded from another host (I tried
> both).
>
> To restate the
On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote:
> On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> > not connected to the real MDIO bus.
> >
> > Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
> > Sig
[snip]
>
> Well I clearly goofed when I added the initial network namespace support
> for /proc/net. Currently things work but there are odd details visible
> to user space, even when we have a single network namespace.
>
> Since we do not cache proc_dir_entry dentries at the moment we can
> ju
Hi Patrick,
I appreciate your comments.
I will update and resend patches.
> > +typedef long long gapclock_t;
>
> It seems you only add to this, does it need to be signed?
> How about using a fixed size type (u64) and getting rid
> of the typedef?
>
OK. I will use u64 instead of gapclock_t, and
1 - 100 of 110 matches
Mail list logo
