s in poll_napi.
Comments?
David, should I submit an updated patch for 2.6.23, or do you
prefer to yank the patch now and try again for 2.6.24?
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To
the main
> reason for such troublesome function as poll_napi: if it's about
> performance isn't this enough to increase budget for netpoll in
> net_rx_action?
I think one reason is that you want to get the kernel oops out even
when the machine is so hosed th
the RX_SCHED bit is that the RX_SCHED
bit and the poll_list change must happen atomically wrt interrupts
from the NIC, right?
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from t
starting
> a NAPI poll.
Understood. How about the patch below? It takes a similar
approach, but it puts the onus on the netpoll code
path rather than the general NAPI case.
Olaf
------
From: Olaf Kirch <[EMAIL PROTECTED]>
Keep netpoll/poll_napi from messing with the poll_l
poll_list. Only net_rx_action
should be allowed to do so. A possible patch is given below
(beware, it's untested so far)
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
From:
an integrated network autoconfiguration
daemon capable of doing DHCP, DHCP6, RDNSS, mDNS, you-name-it
would be a nice thing.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from th
From: Olaf Kirch <[EMAIL PROTECTED]>
Make skb_seq_read unmap the last fragment
Having walked through the entire skbuff, skb_seq_read would leave the
last fragment mapped. As a consequence, the unwary caller would leak
kmaps, and proceed with preempt_count off by one. The only (kind
g
TIME_WAIT will be replaced by an inet_timewait_sock, which is
a kind of truncated inet_sock.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from this list: send the line "unsubscrib
find a piece of code that still uses it, it's most likely something
that hasn't seen a compiler in years - and will likely continue to do
so.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.q
I came across this bug in http://bugzilla.kernel.org/show_bug.cgi?id=8155
Here's a potential fix.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
--
Fix NULL pointer derefence in ipv6_setso
ther PKTINFO cmsg when sending the reply. So it would be
much easier to just store the raw control message in the svc_rqst,
without looking at its contents, and send it out along with the reply,
unchanged.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAI
at the addresses
a little awkward too. And I think to be on the safe side, you
should check that you're really looking at a PKTINFO cmsg
rather than something else.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naythee
just not there now, but it can be added easily, it's one bit in
> the descriptor and a register read in the interrupt handler to see
> which channel(s) need attention.
Hm, okay.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dho
cpying?
I also checked the code in ioatdma.c - I would have expected there to
be some kind of interrupt handler that kicks the upper layers when a
DMA operation completes. But the interrupt handler seems to be for
error reporting exclusively...
Olaf
--
Olaf Kirch | --- o --- Nous somme
Here's a proposed patch that addresses a problem with natsemi
NICs and long cables we've been chasing (*sigh*).
I'm interested in feedback on how to fix this sanely.
Olaf
------
From: Olaf Kirch <[EMAIL PROTECTED]
On Wed, Nov 08, 2006 at 02:07:32PM -0800, Tim Chen wrote:
> In my testing, the CPU utilization is at 100%. So
> increase in ACKs will cost CPU to devote more
> time to process those ACKs and reduce throughput.
Oh, I see. I would test on a real network with real clients. I doubt
you would observe
On Wed, Nov 08, 2006 at 10:38:52AM -0800, Tim Chen wrote:
> The patch in question affects purely TCP and not the scheduler. I don't
I know.
> think the scheduler has anything to do with the slowdown seen after
> the patch is applied.
In fixing performance issues, the most obvious explanation is
On Wed, Nov 08, 2006 at 04:55:18PM +0100, Arjan van de Ven wrote:
> I wonder if it's an option to use low priority QoS fields for these acks
> (heck I don't even know if ACKs have such fields in their packet) so
> that they can get dropped if there are more packets then there is
> bandwidth
I
This is just a minor buglet I came across by accident - when inet_init
fails to register raw_prot, it jumps to out_unregister_udp_proto which
should unregister UDP _and_ TCP.
Signed-off-by: Olaf Kirch <[EMAIL PROTECTED]>
net/ipv4/af_inet.c |4 ++--
1 files changed, 2 insertions
s not a
> new problem at all.
Okay, fine with me - maybe we can convince them to use that
instead.
Thanks for the feedback,
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from
ort with the bogus link-layer address. I tend to agree that it's
incorrect to assign an address at all in this case.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from thi
ULTICAST).
That should work just as well. Do you want me to submit an
updated patch?
Thanks,
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from this list: send the line &qu
netloop device in which case they won't have to disable multicasting
> on the bridge device anymore.
I agree, this would be the right long-term fix.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qu
patch fixes the problem.
Thanks,
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
From: Keir Fraser <[EMAIL PROTECTED]>
Subject: ipv6_add_addr should install dstentry earlier
ipv6_add_ad
p the
device first (and thereby triggering DAD).
The attached tentative patch makes IPv6 autoconf depend on the
availability of IFF_MULTICAST. This is admittedly a bit of a hack, but
it makes sense, since DAD and router solicitation do rely on multicast.
Any comments?
Thanks,
Olaf
--
Olaf
long as they're
bugfix only. Major driver updates at this point would invalidate the
QA that has happened on these already.
> I'll push it into netdev-2.6.git#upstream (and into meta-branch #ALL),
> which means it is queued for 2.6.17 [2.6.16-git1, really]. Once that
Fine with
then do the retry again.
Yes, that is simpler, and should work as well.
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Acked-by: Olaf Kirch <[EMAIL PROTECTED]>
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/
te loop in xfrm_lookup
It seems that the route xfrm_lookup is given on input can go
away when we sleep.
Signed-off-by: Olaf Kirch <[EMAIL PROTECTED]>
net/ipv4/route.c | 25 -
net/xfrm/xfrm_policy.c | 16
2 files changed, 32 insert
On Thu, Jan 26, 2006 at 08:02:37PM +0100, Stefan Seyfried wrote:
> Will be in the next SUSE betas, so if anything breaks, we'll notice
> it.
I doubt it. As Jesse mentioned, e100_hw_init is called from e100_up,
so the call from e100_resume was really superfluous.
Olaf
--
Olaf Kirch
ect, but its taking me a while to set up a system with
> the ability to resume.
I'll ask the folks here to give it a try tomorrow. But I suspect at
least some of it will be needed. For instance I assume you'll
have to reload to ucode when bringing the NIC back from sleep.
Olaf
--
Olaf
On Wed, Jan 25, 2006 at 10:02:40AM +0100, Olaf Kirch wrote:
> I'm not sure what the right fix would be. e100_resume would probably
> have to call e100_alloc_cbs early on, while e100_up should avoid
> calling it a second time if nic->cbs_avail != 0. A tentative patch
> for
re what the right fix would be. e100_resume would probably
have to call e100_alloc_cbs early on, while e100_up should avoid
calling it a second time if nic->cbs_avail != 0. A tentative patch
for testing is attached.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
an ioctl -
so return EAGAIN and let wpa_supplicant handle the problem.
Signed-off-by: Olaf Kirch <[EMAIL PROTECTED]>
drivers/net/wireless/ipw2200.c | 14 ++
1 files changed, 6 insertions(+), 8 deletions(-)
Index: linux
th an
up_write call.
Signed-off-by: Olaf Kirch <[EMAIL PROTECTED]>
rt2x00core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: rt2x00-2.0.0-b3/rt2x00core.c
===
--- rt2x00-2.0.0-b3.orig/rt2x00core.c
+++ rt2x
n; I just did the initial
debugging. But it seems the first patch went into 2.6.10, the other
into 2.6.11-rc1.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from this list: send the l
On Wed, Nov 23, 2005 at 07:01:59PM +0100, Olaf Kirch wrote:
> We've seen this previously, and submitted a fix to netfilter which
> supposedly went into mainline at some point. It seems to be gone
> from 2.6.14 though.
And here are the two patches that came out of the netfilter
disc
n it picks a new port, and succeeds (maybe).
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
On Thu, Nov 17, 2005 at 08:31:07PM +0100, Francois Romieu wrote:
> Olaf Kirch <[EMAIL PROTECTED]> :
> [...]
> > When rtl8169_init_board didn't find the PCI power state
> > capability, it would bail out but return 0 (success).
> > rtl8169_init_one wo
Subject: Fix oops in r8169 driver
When rtl8169_init_board didn't find the PCI power state
capability, it would bail out but return 0 (success).
rtl8169_init_one would then oops trying to dereference
the dev pointer which is NULL.
Signed-off-by: Olaf Kirch <[EMAIL PROTECTED]
le once you unload the ipv6
> module. So I'll leave this alone for now.
>
> So putting your patch and the sock_register() check together
> we end up with the following.
Looks good to me.
Thanks,
Olaf
--
Olaf Kirch | --- o --- Nous sommes du solei
ject: inet6_init: cleanup after failed initialization
When initialization fails in inet6_init(), we should
unregister the PF_INET6 socket ops.
Signed-off-by: Olaf Kirch <[EMAIL PROTECTED]>
Index: linux-2.6.14/net/ipv6/
etup/teardown.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
From: Olaf Kirch <[EMAIL PROTECTED]>
Subject: [IPv4] Prevent oops when printing martian source
In some cases, we may be genera
42 matches
Mail list logo
