Hi,
I've a question regarding bytes_received and bytes_sent.
https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_output.c#L1385
In net/ipv4/tcp_output.c
if (skb->len != tcp_header_size) {
tcp_event_data_sent(tp, sk);
tp->data_segs_out += tcp_skb_pcount(skb);
tp->bytes_sent += skb->le
I'm trying to track down a problem with systemd-networkd; on three of
my machines, I have 'IPv6ProxyNDPAddress' configured in the network
configuration file so that additional addresses will be added when the
interface comes up.
Unfortunately, even though systemd-networkd is adding the addresses,
On Fri, 2019-05-17 at 14:01 -0700, Rick Edgecomb e wrote:
> Meelis Roos reported issues with the new VM_FLUSH_RESET_PERMS flag on
> the
> sparc architecture.
>
Argh, this patch is not correct in the flush range for non-x86. I'll
send a revision.
Hi,
After investigating this more, I am not positive why this fixes the
issue on sparc. I will continue to investigate as best I can, but would
like to request help from some sparc experts on evaluating my line of
thinking. I think the changes in this patch are still very worthwhile
generally thou
On Mon, 2019-05-13 at 10:01 -0700, Rick Edgecombe wrote:
> On Mon, 2019-05-13 at 17:01 +0300, Meelis Roos wrote:
> > I tested yesterdays 5.2 devel git and it failed to boot on my Sun Fire V445
> > (4x UltraSparc III). Init is started and it hangs there:
> >
> > [ 38.414436] Run /sbin/init as ini
On Mon, 2019-05-13 at 17:01 +0300, Meelis Roos wrote:
> I tested yesterdays 5.2 devel git and it failed to boot on my Sun Fire V445
> (4x UltraSparc III). Init is started and it hangs there:
>
> [ 38.414436] Run /sbin/init as init process
> [ 38.530711] random: fast init done
> [ 39.580678]
On Wed, 2019-02-06 at 00:35 +, Alexei Starovoitov wrote:
> On 2/5/19 2:50 PM, Rick Edgecombe wrote:
> > This introduces a new capability for BPF program JIT's to be located in
> > vmalloc
> > space on x86_64. This can serve as a backup area for
> > CONFIG_BPF_JIT_ALWAYS_ON in
> > case an unpriv
Correct two minor kerneldoc errors:
1) missing reference to @mode in struct phy_ops
2) obsolete reference to @init_data in struct_phy_attrs,
removed in dbc98635e0d42f0e62ea92813df1e0e4c90f8375
Signed-off-by: Robert P. J. Day
---
AFAICT, none of this is actually included in the
1) note that gianfar_phy.c was removed years ago
2) fix obvious copy and paste error in regular doc
3) change regular doc into kerneldoc for phy_modes()
Signed-off-by: Robert P. J. Day
---
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3ea87f774a76..e040f3ab4c7a 100644
--- a
On Wed, 26 Dec 2018, Andrew Lunn wrote:
> On Wed, Dec 26, 2018 at 05:41:29AM -0600, Robert P. J. Day wrote:
> >
> > 1) gianfar_phy.c should clearly refer to gianfar.c
> > 2) fix obvious copy and paste error in regular doc
> > 3) change regular doc into kerneldoc for
1) gianfar_phy.c should clearly refer to gianfar.c
2) fix obvious copy and paste error in regular doc
3) change regular doc into kerneldoc for phy_modes()
Signed-off-by: Robert P. J. Day
---
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 3ea87f774a76..1ca94a51a93e 100644
On Mon, 2018-12-17 at 05:41 +0100, Jessica Yu wrote:
> +++ Edgecombe, Rick P [12/12/18 23:05 +]:
> > On Wed, 2018-11-28 at 01:40 +, Edgecombe, Rick P wrote:
> > > On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote:
> > > > On 11/27/2018 01:19 AM, Edgecom
On Sat, 2018-12-15 at 10:52 -0800, Andy Lutomirski wrote:
> On Wed, Dec 12, 2018 at 2:01 PM Edgecombe, Rick P
> wrote:
> >
> > On Wed, 2018-12-12 at 11:57 -0800, Andy Lutomirski wrote:
> > > On Wed, Dec 12, 2018 at 11:50 AM Edgecombe, Rick P
> > > wrote:
&g
On Thu, 2018-12-13 at 19:27 +, Nadav Amit wrote:
> > On Dec 13, 2018, at 11:02 AM, Edgecombe, Rick P
> > wrote:
> >
> > On Wed, 2018-12-12 at 23:40 +, Nadav Amit wrote:
> > > > On Dec 11, 2018, at 4:03 PM, Rick Edgecombe
> > > > wrote:
>
Signed-off-by: Robert P. J. Day
---
diff --git a/include/linux/mod_devicetable.h
b/include/linux/mod_devicetable.h
index 01797cb4587e..a0dcc9b6a723 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -565,7 +565,7 @@ struct platform_device_id
On Wed, 2018-12-12 at 23:40 +, Nadav Amit wrote:
> > On Dec 11, 2018, at 4:03 PM, Rick Edgecombe
> > wrote:
> >
> > Add new flags for handling freeing of special permissioned memory in
> > vmalloc,
> > and remove places where the handling was done in module.c.
> >
> > This will enable this f
On Wed, 2018-11-28 at 01:40 +, Edgecombe, Rick P wrote:
> On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote:
> > On 11/27/2018 01:19 AM, Edgecombe, Rick P wrote:
> > > On Mon, 2018-11-26 at 16:36 +0100, Jessica Yu wrote:
> > > > +++ Rick E
On Wed, 2018-12-12 at 11:57 -0800, Andy Lutomirski wrote:
> On Wed, Dec 12, 2018 at 11:50 AM Edgecombe, Rick P
> wrote:
> >
> > On Tue, 2018-12-11 at 18:20 -0800, Andy Lutomirski wrote:
> > > On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe
> > > wrote:
>
* executable we need to make sure there is no W window on the directmap
> > +* before removing the X in the TLB. So we set not present first so we
> > +* can flush without any other CPU picking up the mapping. Then we reset
> > +* RW+P without a flush, si
ed to make sure to reset the direct map perms */
> > +
> > + /*
> > +* If the area being freed does not have any extra capabilities, we
> > can
> > +* just reset the directmap to RW before freeing.
> > +*/
> > + if (
gt; #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -38,6 +39,11 @@
> >
> > #include "internal.h"
> >
> > +struct vfree_work {
> > + struct llist_node
On Thu, 2018-12-06 at 15:08 -0800, Nadav Amit wrote:
> > On Dec 6, 2018, at 12:17 PM, Andy Lutomirski wrote:
> >
> > On Thu, Dec 6, 2018 at 11:39 AM Nadav Amit wrote:
> > > > On Dec 6, 2018, at 11:19 AM, Andy Lutomirski wrote:
> > > >
> > > > On Thu, Dec 6, 2018 at 11:01 AM Tycho Andersen wro
On Thu, 2018-12-06 at 11:19 -0800, Andy Lutomirski wrote:
> On Thu, Dec 6, 2018 at 11:01 AM Tycho Andersen wrote:
> >
> > On Thu, Dec 06, 2018 at 10:53:50AM -0800, Andy Lutomirski wrote:
> > > > If we are going to unmap the linear alias, why not do it at vmalloc()
> > > > time rather than vfree()
On Tue, 2018-12-04 at 16:53 -0800, Nadav Amit wrote:
> > On Dec 4, 2018, at 4:29 PM, Edgecombe, Rick P
> > wrote:
> >
> > On Tue, 2018-12-04 at 16:01 -0800, Nadav Amit wrote:
> > > > On Dec 4, 2018, at 3:51 PM, Edgecombe, Rick P <
> >
On Tue, 2018-12-04 at 14:48 -0800, Nadav Amit wrote:
> > On Dec 4, 2018, at 11:48 AM, Andy Lutomirski wrote:
> >
> > On Tue, Dec 4, 2018 at 11:45 AM Nadav Amit wrote:
> > > > On Dec 4, 2018, at 10:56 AM, Andy Lutomirski wrote:
> > > >
> > > > On Mon, Dec 3, 2018 at 5:43 PM Nadav Amit wrote:
>
On Tue, 2018-12-04 at 16:01 -0800, Nadav Amit wrote:
> > On Dec 4, 2018, at 3:51 PM, Edgecombe, Rick P
> > wrote:
> >
> > On Tue, 2018-12-04 at 12:36 -0800, Nadav Amit wrote:
> > > > On Dec 4, 2018, at 12:02 PM, Edgecombe, Rick P <
> >
On Tue, 2018-12-04 at 12:09 -0800, Andy Lutomirski wrote:
> On Tue, Dec 4, 2018 at 12:02 PM Edgecombe, Rick P
> wrote:
> >
> > On Tue, 2018-12-04 at 16:03 +, Will Deacon wrote:
> > > On Mon, Dec 03, 2018 at 05:43:11PM -0800, Nadav Amit wrote:
> > > &
On Tue, 2018-12-04 at 16:03 +, Will Deacon wrote:
> On Mon, Dec 03, 2018 at 05:43:11PM -0800, Nadav Amit wrote:
> > > On Nov 27, 2018, at 4:07 PM, Rick Edgecombe
> > > wrote:
> > >
> > > Since vfree will lazily flush the TLB, but not lazily free the underlying
> > > pages,
> > > it often leav
It looks like this new flag is in linux-next now. As I am reading it, these
architectures have a module_alloc that uses some sort of executable flag and
are not using the default module_alloc which is already covered, and so may need
it plugged in:
arm
arm64
parisc
s390
unicore32
Thanks,
Rick
On
On Thu, 2018-11-29 at 23:06 +0900, Masami Hiramatsu wrote:
> On Tue, 27 Nov 2018 16:07:52 -0800
> Rick Edgecombe wrote:
>
> > Sometimes when memory is freed via the module subsystem, an executable
> > permissioned TLB entry can remain to a freed page. If the page is re-used to
> > back an address
> > +++ b/arch/x86/kernel/module.c
> > @@ -87,8 +87,8 @@ void *module_alloc(unsigned long size)
> >p = __vmalloc_node_range(size, MODULE_ALIGN,
> >MODULES_VADDR + get_module_load_offset(),
> >MODULES_END, GFP_KERNE
b/arch/x86/kernel/module.c
> > @@ -87,8 +87,8 @@ void *module_alloc(unsigned long size)
> > p = __vmalloc_node_range(size, MODULE_ALIGN,
> > MODULES_VADDR + get_module_load_offset(),
> > MODULES_END
On Tue, 2018-11-27 at 11:21 +0100, Daniel Borkmann wrote:
> On 11/27/2018 01:19 AM, Edgecombe, Rick P wrote:
> > On Mon, 2018-11-26 at 16:36 +0100, Jessica Yu wrote:
> > > +++ Rick Edgecombe [20/11/18 15:23 -0800]:
> >
> > [snip]
> > > Hi Rick!
> > >
On Fri, 2018-11-23 at 23:18 +0100, Ard Biesheuvel wrote:
> By default, BPF uses module_alloc() to allocate executable memory,
> but this is not necessary on all arches and potentially undesirable
> on some of them.
>
> So break out the module_alloc() and module_memfree() calls into __weak
> functi
Le lundi 29 octobre 2018, 23:03:07 CET Stefano Brivio a écrit :
> On Mon, 29 Oct 2018 21:06:35 +0100
>
> "Yoann P." wrote:
> > > By the way, why do you use column(1), when ss already prints output in
> > > columns? Any other issue you are working around?
>
> On Mon, 29 Oct 2018 19:20:36 +0100
>
> Stefano Brivio wrote:
> > The actual issue seems to be that in some cases the left delimiter for
> > the State column is not printed
>
> Much worse, we always print the left delimiter of the last buffered
> column, which is usually empty. My bad.
>
>
> Hi Yohann,
>
> On Fri, 26 Oct 2018 22:53:32 +0200
>
> "Yoann P." wrote:
> > When using ss -Hutn4 or -utn3, Netid and State columns are sometime
> > merged, it can be confusing when trying to pipe into awk or column.
>
> Thanks for fixing this.
When using ss -Hutn4 or -utn3, Netid and State columns are sometime merged, it
can be confusing when trying to pipe into awk or column.
Details (before and after output) are available on this github issue: https://
github.com/shemminger/iproute2/issues/20
Signed-off-by: YoyPa
---
misc/ss.c | 6
To be consistent with subsequent error message specifically mentioning
zero RX queues, add a reference to TX queues to the error message.
Signed-off-by: Robert P. J. Day
---
diff --git a/net/core/dev.c b/net/core/dev.c
index 325fc5088370..a5d0c2244fb5 100644
--- a/net/core/dev.c
+++ b/net/core
;s doing in those two places.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
ients
but, as a contractor, i have little influence. but i will continue to
make them.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
On Sun, 26 Aug 2018, Stephen Hemminger wrote:
> On Sun, 26 Aug 2018 11:14:33 -0400 (EDT)
> "Robert P. J. Day" wrote:
>
> > apologies for the constant pleas for assistance, but i think i'm
> > zeroing in on the problem that started all this. recap: custom
&g
On Sun, 26 Aug 2018, Stephen Hemminger wrote:
> On Sun, 26 Aug 2018 15:20:24 -0400 (EDT)
> "Robert P. J. Day" wrote:
>
> > On Sun, 26 Aug 2018, Andrew Lunn wrote:
> >
> > > > i ask since, in my testing, when the interface should have been
> >
On Sun, 26 Aug 2018, Andrew Lunn wrote:
> On Sun, Aug 26, 2018 at 03:20:24PM -0400, Robert P. J. Day wrote:
> > On Sun, 26 Aug 2018, Andrew Lunn wrote:
> >
> > > > i ask since, in my testing, when the interface should have been
> > > > up, the attrib
On Sun, 26 Aug 2018, Andrew Lunn wrote:
> On Sun, Aug 26, 2018 at 11:14:33AM -0400, Robert P. J. Day wrote:
> >
> > apologies for the constant pleas for assistance, but i think i'm
> > zeroing in on the problem that started all this. recap: custom
> > FPGA-bas
t; virtual device like tun/tap.
i wish, but i'm on contract, and proprietary, and NDA and all that.
so i am reduced to crawling through the code, trying to figure out
what is misconfigured that is causing all this grief.
rday
--
====
o one to learn that this aspect was
misprogrammed.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
tever
that means)?
i ask since, in my testing, when the interface should have been up,
the attribute file "operstate" for that interface showed "unknown",
and i wondered how worried i should be about that.
rday
--
===
ven look at
them in that location and instead invokes the respective functions. do
i have that about right, before i crawl further down this rabbit hole?
it's all starting to make sense.
rday
--
====
Robert P. J. Day
Correct the references for both flags and priv flags since they both
refer to the incorrect file which contains their explanations.
Signed-off-by: Robert P. J. Day
---
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index ca5ab98053c8..f01f3473bb91 100644
--- a/include/linux
On Wed, 22 Aug 2018, Stephen Hemminger wrote:
> On Wed, 22 Aug 2018 18:32:36 -0400 (EDT)
> "Robert P. J. Day" wrote:
>
> > almost certainly another dumb question, but i was poking around the
> > sysfs, particularly /sys/class/net//*, to familiarize myself
> &
with some of those flags being
"volatile" as dewscribed in include/uapi/linux/if.h? or am i just
totally misreading this?
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
On Sat, 18 Aug 2018, Willy Tarreau wrote:
> On Sat, Aug 18, 2018 at 09:10:25PM +0200, Andrew Lunn wrote:
> > On Sat, Aug 18, 2018 at 01:39:50PM -0400, Robert P. J. Day wrote:
> > >
> > > (i'm sure this has been explained many times before, so a link
> > &g
erfaces into two new namespaces, and
setting up forwarding.
anyway, a recipe for this would be just ducky. thank you kindly.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
well if the C preprocessor ever gets
ahold of it.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
On Sun, 5 Aug 2018, Andrew Lunn wrote:
> On Sat, Aug 04, 2018 at 07:06:58AM -0400, Robert P. J. Day wrote:
> >
> > i'll try to keep this (relatively) short as there may be a
> > simple answer to this, or it could just be a stupid question --
> > sort of related
r
so i am reduced to concluding that the drivers in question are simply
not calling correctly the very routines you mention.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn:
mation.
> >
> > i'm about to ask the original authors why they did the above, but
>
> I guess that the reason is that they had no clue what they are doing
> :)
given that i've been immersed in networking code for only a few
days, i was not about to draw any conclu
ebugging
feature that would normally be removed at production? or what?
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter:
On Wed, 1 Aug 2018, Florian Fainelli wrote:
> On 08/01/2018 05:58 AM, rpj...@crashcourse.ca wrote:
> >
> > (warning that i have a few questions that are probably trivial
> > until i get up to speed with networking code.)
> >
> > a colleague asked for advice about the following -- apparently a
Move the "device present" mask bits up immediately after the MMD
device definitions, since it makes no sense to have them further down
in the file.
This is purely a cosmetic change for readability.
Signed-off-by: Robert P. J. Day
---
since the *only* thing that actually us
On Thu, Jan 11, 2018 at 02:03:05AM +, Kees Cook wrote:
> This whitelists the FPU register state portion of the thread_struct for
> copying to userspace, instead of the default entire structure.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Christian Borntraeger
> Cc: Ingo Molnar
> Cc: Jam
Hi Bhadram,
Does the Tegra by any chance have TSO enabled on multiple TX-DMA channels ?
I recently noticed a second TSO bug in the stmmac while making the
patch "stmmac: reset last TSO segment size after device open".
The last-used MSS setting in TSO is tracked as a device-global
variable and no
list:TI NETCP ETHERNET DRIVER; David Miller; HEISE, Peter P
Betreff: Re: Redundancy support through HSR and PRP
On 2016-10-24 18:35, Murali Karicheri wrote:
>> On 10/10/2016 02:34 PM, Murali Karicheri wrote:
>>> All,
>>>
>>> Wondering if there plan to add PRP drive
On Thu, 29 Oct 2015 17:01:24 -0700
Ani Sinha wrote:
> On Wed, Oct 28, 2015 at 11:40 PM, Neal P. Murphy
> wrote:
> > On Wed, 28 Oct 2015 02:36:50 -0400
> > "Neal P. Murphy" wrote:
> >
> >> On Mon, 26 Oct 2015 21:06:33 +0100
> >> Pablo Neir
On Wed, 28 Oct 2015 02:36:50 -0400
"Neal P. Murphy" wrote:
> On Mon, 26 Oct 2015 21:06:33 +0100
> Pablo Neira Ayuso wrote:
>
> > Hi,
> >
> > On Mon, Oct 26, 2015 at 11:55:39AM -0700, Ani Sinha wrote:
> > > netfilter: nf_conntrack: fix RCU race in
patches to netfilter-de...@vger.kernel.org.
>
> Moreover, it would be great if the subject includes something
> descriptive on what you need, for this I'd suggest:
>
> [PATCH -stable 3.4,backport] netfilter: nf_conntrack: fix RCU race in
> nf_conntrack_find_get
>
>
> > + fprintf(stderr, "\nNOTE: CLASSID is parsed as hexidecimal
> > +input.\n");
>
> s/hexidecimal/hexadecimal/g (?)
Gah! Thanks Jarek, I can correct and resend.
-PJ Waskiewicz
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
> Sorry, can't change the api, update the documentation instead.
Yes, this is much more reasonable. I'll send a patch shortly to do
that.
Thanks
-PJ Waskiewicz
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
ed to be base 16. What do you think?
Thanks,
-PJ Waskiewicz
[EMAIL PROTECTED]
>
> Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
> ---
>
> tc/tc_util.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tc/tc_util.c b/tc/
> I totally disagree with these POVs:
>
> - 10G cards should be treated by default as 10G cards - not
> DSL modems,
> and common users shouldn't have to read any warnings or configs to
> see this.
> - tc with TBF or HTB are professional tools; there should be
> added some
> warnings to man
> I've changed the -EIO into NETDEV_TX_BUSY and so far I can't
> trigger the bug anymore. It was quite easy to trigger within
> minutes with rsync, but I can't trigger it anymore. Should I
> send a patch, and if
> so: to who? The tulip/xircom_cb driver seems to be orphaned.
Perhaps Jeff Garzik
> Right - Essentially it is a usability issue:
> People who know how to use TSO (Peter for example) will be
> clueful enough to turn it on. Which means the default should
> be to protect the clueless and turn it off.
> On Andis approach:
> Turning TSO off at netdev registration time with a warnin
> Indeed. As an example of an unknowing user, this discussion
> made me check whether my cablemodem device (on which I'm
> using HFSC) uses TSO :)
The TSO defer logic is based on your congestion window and current
window size. So the actual frame sizes hitting your NIC attached to
your DSL prob
> ...But, on the other hand, in this case the realization seems to be
> wrong: probably still all locally created packets will be
> treated the same - or I miss something?
>
> Jarek P.
The TCP layer will generate TSO packets based on the kernel socket
features associated with t
> Well, it could be just that when using such qdiscs TSO would be
> disabled, but the user could override this by using ethtool after
> loading the qdiscs.
I still disagree with this. The qdisc should not cause anything to happen to
feature flags on the device. It's the scheduling layer and real
> The philosophical problem I have with this suggestion is that
> I expect that the large majority of users will be more happy
> with disabled TSO if they use non standard qdiscs and
> defaults that do not fit the majority use case are bad.
>
> Basically you're suggesting that nearly everyone u
> My point was that without TSO different submitters will
> interleave their streams (because they compete about the
> qdisc submission) and then you end up with a smooth rate over
> time for all of them.
>
> If you submit in large chunks only (as TSO does) it will
> always be more bursty and
> Peter, I suspect that driver is just buggy in some other way
> as opposed to being re-entered; couldnt tell by inspection.
> It is possible it may be too eager to open up before it
> really has space.
> It will be easy to check your theory by having the driver
> just check if it is netif_stop
> > Are you using any specific qdisc, or just the default pfifo_fast?
> > Have you done any specific tuning on your qdisc as well?
> The default
> > qlen seems to have been changed.
>
> The driver seems buggy. Make it return NETDEV_TX_BUSY instead
> of -EIO in xircom_start_xmit() and the me
> I've just started to use 2.6.24 on my home firewall (before
> it was running 2.6.24-rc2 for about 65 days) and I noticed a
> couple of error messages I've never seen before:
>
> Jan 29 07:50:54 gateway kernel: BUG eth1 code -5 qlen 0 Jan
> 29 08:28:30 gateway kernel: BUG eth1 code -5 qlen 0 J
On Mon, 26 Nov 2007, Joonwoo Park wrote:
> 2007/11/26, Robert P. J. Day <[EMAIL PROTECTED]>:
> > i realized that. but all you can say is that only amb_init() calls
> > setup_dev() *currently*. when you're not looking, someone else might
> > (for whatever reason)
On Mon, 26 Nov 2007, Joonwoo Park wrote:
> 2007/11/26, Robert P. J. Day <[EMAIL PROTECTED]>:
> > i'm not sure the above is a safe thing to do, as you're zeroing that
> > area, then making a function call and assuming, upon entry to the
> > function call, tha
oppy about it. unless you're
prepared to guarantee that there will never be another call to
setup_dev() from elsewhere.
rday
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
memset(n, 0, sz);
> + n = kzalloc(sz, GFP_KERNEL);
> + else {
> + if (hashdist)
i believe the more common standard for the above is:
else if (hashdist) {
to reduce the level of overall indentation, no?
rday
=
> You could optimize this by getting HARD_TX_LOCK after the
> check. I assume that netif_stop_subqueue (from another CPU)
> would always be called by the driver xmit, and that is not
> possible since we hold the __LINK_STATE_QDISC_RUNNING bit.
> Does that sound correct?
Sorry for not respondin
e.
rday
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
-
To unsubscribe from t
Given that it's well established that the "ether=" kernel parameter is
deprecated in favour of the newer "netdev=", might as well make it
official.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
Documentation/feature-removal-schedule.txt |
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 07, 2007 3:52 AM
> To: Waskiewicz Jr, Peter P
> Cc: netdev@vger.kernel.org
> Subject: Re: [PATCH] [AF_PACKET]: Allow multicast traffic to
> be caught by ORIGDEV
are.
> >
> > Signed-off-by: Peter P Waskiewicz Jr
> <[EMAIL PROTECTED]>
>
> I agree with you in principle, but I'd like to hear some
> feedback from other folks. In particular I'd like a
> discussion about what this might break, if anything.
That&#
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
i'm just going to assume that loop is rounding up to the next power
of two, right?
diff --git a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c
index db6a97d..07eae16 100644
--- a/drivers/net/pcmcia/pcnet
> From: Rick Jones <[EMAIL PROTECTED]>
> Date: Thu, 11 Oct 2007 16:50:46 -0700
>
> > For just messing about, might it be possible to tweak the socket
> > buffer sizes and tcp_tso_win_divisor to kludge things for a short
> > while? Couldn't ship that way certainly, but assuming
> Peter's going
I'm having an issue with TSO right vs. hardware that can't take the
maximum segment size sent from the stack. I've been told that the
maximum packet size that can be sent to the hardware today is 64k, but
my hardware can only take 32k in certain modes per queue due to hardware
limitations. I have
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 10, 2007 9:02 AM
> To: Waskiewicz Jr, Peter P
> Cc: David Miller; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Wed, 10 Oct 2007 12:23:31 +0200
>
> > On Wed, Oct 10, 2007 at 02:25:50AM -0700, David Miller wrote:
> > > The chip I was working with at the time (UltraSPARC-IIi)
> compressed
> > > all the linear stores into 64-byte full cacheline
> transactions v
> A misunderstanding, I think.
>
> To my brain, DaveM's item #2 seemed to assume/require the NIC
> hardware to balance fairly across hw TX rings, which seemed
> to preclude the
> 8139cp/tg3 style of strict-prio hardware. That's what I was
> responding to.
>
> As long as there is some modular
> IMO the net driver really should provide a hint as to what it wants.
>
> 8139cp and tg3 would probably prefer multiple TX queue
> behavior to match silicon behavior -- strict prio.
If I understand what you just said, I disagree. If your hardware is
running strict prio, you don't want to enfor
> If net_device_subqueue is visible from both driver and core
> scheduler area (couldnt tell from looking at whats in there
> already), then that'll do it.
Yes, I use the net_device_subqueue structs (the state variable in there)
in the prio and rr qdiscs right now. It's an indexed list at the
> Multiply whatever effect you think you might be able to
> measure due to that on your 2 or 4 way system, and multiple
> it up to 64 cpus or so for machines I am using. This is
> where machines are going, and is going to become the norm.
That along with speeds going to 10 GbE with multiple Tx
1 - 100 of 317 matches
Mail list logo
