On Sun, Nov 18, 2007 at 03:56:11PM +0100, Ingo Molnar wrote:
>
> * Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> > On Tue 2007-11-13 12:50:08, Mark Lord wrote:
> > > Ingo Molnar wrote:
> > > >
> > > >for example git-bisect was godsent. I remember that
> > > >years ago bisection of a bug was a very
On Sun, Nov 18, 2007 at 02:40:10PM -0800, David Miller wrote:
>
> This can be fixed, the above cannot.
That's a good point. Perhaps one way of getting that info to
the user without putting it in UDPInDatagrams is to create an
inet_diag interface for UDP and put the number of queued packets
for ea
David Miller said the following on 2007-11-19 6:40:
> We could defer the increment until we check the checksum,
> but that is likely to break even more things because people
> (as Wang Chen did initially) will send a packet to some
> port with an app that doesn't eat the packets, and expect the
> I
On 11/9/07, Grant Likely <[EMAIL PROTECTED]> wrote:
> On 11/9/07, Domen Puncer <[EMAIL PROTECTED]> wrote:
> > On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > > This is the reason I couldn't get user space started or connect to my
> > > nfs server. Patch is against current linus git.
> > >
> > > mpc52
David Miller <[EMAIL PROTECTED]> wrote:
>
> I'm getting this without IPSEC FWIW. I believe it occurs when I talk
> to sites with sub-1500 MTUs.
It is possible to get this with any MTU that's not a multiple
of 4. I was basing my comment above on the fact that such MTUs
are usually rare. However,
On Sun, Nov 18, 2007 at 02:40:10PM -0800, David Miller wrote:
>
> The networking stack DID receive the packet. Just because a socket
> owner is busy doing something else or blocked on some other event
> is no excuse not to bump the InDataGgrams counter.
Actually if we ever implement the memory re
skb is only NULL the first time around: it's more correct to test for
being under-budget.
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 2a94425ac7d5 drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c Thu Nov 15 13:47:28 2007 +1100
+++ b/drivers/net/virtio_net.c Thu Nov 15 23:10:
This fixes a potential dangling xmit problem.
We also suppress refill interrupts until we need them.
(Anthony and I have been working on performance recently, so this
is a WIP).
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
diff -r 586fb6ff29dd drivers/net/virtio_net.c
--- a/drivers/net/virti
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sun, 18 Nov 2007 22:45:15 +0100
> > We could defer the increment until we check the checksum,
> > but that is likely to break even more things because people
> > (as Wang Chen did initially) will send a packet to some
> > port with an app that doesn't eat
David Miller wrote:
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Sat, 17 Nov 2007 14:18:46 +0100
Wang Chen <[EMAIL PROTECTED]> writes:
Herbert Xu said the following on 2007-11-16 12:11:
Wang Chen <[EMAIL PROTECTED]> wrote:
So, I think the checksum in udp_queue_rcv_skb(
> We could defer the increment until we check the checksum,
> but that is likely to break even more things because people
> (as Wang Chen did initially) will send a packet to some
> port with an app that doesn't eat the packets, and expect the
> InDatagrams counter to increase once the stack eats t
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 18 Nov 2007 20:15:30 +0800
> [TCP]: Fix TCP header misalignment
>
> Indeed my previous change to alloc_pskb has made it possible
> for the TCP header to be misaligned iff the MTU is not a multiple
> of 4 (and less than a page). So I suspect the opt
Denys <[EMAIL PROTECTED]> :
>
> Before it happens on 2.6.22, i tried to attach good cable, plug-unplug,
> whatever, interface up/down - card still remains dead.
A few things have changed since 2.6.22 but I'll take that it is a
real bug and that 2.6.23 would not recover either. Can you fill a
PR
I'm trying to get the iwl3945 driver working on my laptop, using the
latest kernels.
Upon boot, when udev loads the driver, it does not create the proper
device. This is the contents of the kernel log:
[ 29.694882] iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection
[ 29.781011]
David wrote:
Ismail Dönmez wrote:
Sunday 18 November 2007 Tarihinde 21:00:12 yazmıştı:
I'm (very) far from being firewall configuration expert, but I'm seeing
a consistent kernel panic when the following rule is triggered.
iptables -t nat -A PREROUTING -j REDIRECT -i eth2 -p udp
Ismail Dönmez wrote:
> Sunday 18 November 2007 Tarihinde 21:00:12 yazmıştı:
>
>> I'm (very) far from being firewall configuration expert, but I'm seeing
>> a consistent kernel panic when the following rule is triggered.
>>
>> iptables -t nat -A PREROUTING -j REDIRECT -i eth2 -p udp --dport
>
Sunday 18 November 2007 Tarihinde 21:00:12 yazmıştı:
> I'm (very) far from being firewall configuration expert, but I'm seeing
> a consistent kernel panic when the following rule is triggered.
>
> iptables -t nat -A PREROUTING -j REDIRECT -i eth2 -p udp --dport
> 5061 --to-ports 5060
>
> (I'm t
I'm (very) far from being firewall configuration expert, but I'm seeing
a consistent kernel panic when the following rule is triggered.
iptables -t nat -A PREROUTING -j REDIRECT -i eth2 -p udp --dport
5061 --to-ports 5060
(I'm trying to redirect an alternate port to a SIP server)
Am I just b
On Wed, Oct 31, 2007 at 01:56:53PM +0100, Peter Zijlstra wrote:
>On Wed, 2007-10-31 at 08:16 -0400, Jeff Garzik wrote:
>> Thoughts:
>> 1) I absolutely agree that NFS is far more prominent and useful than any
>> network block device, at the present time.
>>
>> 2) Nonetheless, swap over NFS is a
On 18-11-07 15:35, James Bottomley wrote:
clean-cg? But failure to run "git repack -a -d" every once in a while?
Actually, the best command is
git gc
which does a repack (into a single pack file rather than an incremenal),
and then removes all the objects now in the pack. If, like me, you
* Pavel Machek <[EMAIL PROTECTED]> wrote:
> On Tue 2007-11-13 12:50:08, Mark Lord wrote:
> > Ingo Molnar wrote:
> > >
> > >for example git-bisect was godsent. I remember that
> > >years ago bisection of a bug was a very laborous task
> > >so that it was only used as a final, last-ditch
> > >ap
On Sun, 2007-11-18 at 13:58 +0100, Rene Herman wrote:
> On 18-11-07 13:44, Pavel Machek wrote:
>
> > On Tue 2007-11-13 12:50:08, Mark Lord wrote:
>
> >> It's a 540MByte download over a slow link for everyone
> >> else.
> >
> > Hmmm, clean-cg is 7.7G on my machine, and yes I tried
> > git-prune
On 18-11-07 13:44, Pavel Machek wrote:
On Tue 2007-11-13 12:50:08, Mark Lord wrote:
It's a 540MByte download over a slow link for everyone
else.
Hmmm, clean-cg is 7.7G on my machine, and yes I tried
git-prune-packed. What am I doing wrong?
clean-cg? But failure to run "git repack -a -d" e
On Tue 2007-11-13 12:50:08, Mark Lord wrote:
> Ingo Molnar wrote:
> >
> >for example git-bisect was godsent. I remember that
> >years ago bisection of a bug was a very laborous task
> >so that it was only used as a final, last-ditch
> >approach for really nasty bugs. Today we can
> >autonomouly
Hi Dave:
[TCP]: Fix TCP header misalignment
Indeed my previous change to alloc_pskb has made it possible
for the TCP header to be misaligned iff the MTU is not a multiple
of 4 (and less than a page). So I suspect the optimised IPsec
MTU calculation is giving you just such an MTU :)
This patch f
25 matches
Mail list logo
