-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Now, I started the heartbeat process on the same machine, and it blew up
trying to do something with IPaddr. I can't even sysrq the box back into
life at this point :-/
BUG: unable to handle kernel paging request at virtual address 9e045900
printing
David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Mon, 31 Jul 2006 06:24:31 +0200
>
>
>>This is a known problem with NAT and HW checksum and will probably get
>>fixed in 2.6.19.
>
>
> I would like to see this fixed for 2.6.18, no later.
>
> Either that or disable the bug
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 21:34:37 -0700
> Several people are reporting this. It's apparently harmless and
> serves as a(n odd) way for the net guys to remind themselves that
> this needs fixing.
>
> It'd be nice to not let this escape into 2.6.18, please?
I'
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 06:24:31 +0200
> This is a known problem with NAT and HW checksum and will probably get
> fixed in 2.6.19.
I would like to see this fixed for 2.6.18, no later.
Either that or disable the bug trap, but taking this route
is severely
On Mon, 31 Jul 2006 00:16:21 -0400
David Coulson <[EMAIL PROTECTED]> wrote:
> This machine has four NICs running the e1000 kernel module. Other than
> the BUG() messages, it seems to be running fine. I was running 2.6.15.4
> without any issues on the same hardware, although I noticed the e1000
> h
On Sun, Jul 30, 2006 at 03:59:56PM -0700, David Miller wrote:
> From: Sam Ravnborg <[EMAIL PROTECTED]>
> Date: Mon, 31 Jul 2006 00:45:43 +0200
>
> > >From a pure eye-candy perspective it would be nice to use same format
> > all over.
> > >From Documentation/SubmittingPatches:
> > -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a machine running 2.6.18-rc3 with a bridge config that looks like
this:
cr1:~# brctl show
bridge name bridge id STP enabled interfaces
vlan100 36b0.0007e90f40c1 yes eth0.100
On Sun, Jul 30, 2006 at 10:32:10PM -0500, Matt Domsch wrote:
> On Sun, Jul 30, 2006 at 03:44:16PM -0700, David Miller wrote:
> > From: Herbert Xu <[EMAIL PROTECTED]>
> > Date: Sat, 29 Jul 2006 14:33:25 +1000
> >
> > > [IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
> > >
> > > The current us
David Coulson wrote:
> This machine has four NICs running the e1000 kernel module. Other than
> the BUG() messages, it seems to be running fine. I was running 2.6.15.4
> without any issues on the same hardware, although I noticed the e1000
> has been updated (and I went for rc3 since I was hitting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This machine has four NICs running the e1000 kernel module. Other than
the BUG() messages, it seems to be running fine. I was running 2.6.15.4
without any issues on the same hardware, although I noticed the e1000
has been updated (and I went for rc3 si
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 06:06:37 +0200
> Herbert Xu wrote:
> > On Tue, Jul 25, 2006 at 02:09:26AM +0200, Patrick McHardy wrote:
> >
> >>[XFRM]: Fix protocol field value for outgoing IPv6 GSO packets
> >>
> >>Signed-off-by: Patrick McHardy <[EMAIL PROTECTED
Hi Dave,
Herbert Xu wrote:
> On Tue, Jul 25, 2006 at 02:09:26AM +0200, Patrick McHardy wrote:
>
>>[XFRM]: Fix protocol field value for outgoing IPv6 GSO packets
>>
>>Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
>
> Acked-by: Herbert Xu <[EMAIL PROTECTED]>
I believe you missed this one. At
From: Matt Domsch <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 22:32:10 -0500
> swapper/0 is trying to acquire lock:
> (slock-AF_INET6){-+..}, at: [] sk_clone+0xd2/0x3a8
>
> but task is already holding lock:
> (slock-AF_INET6){-+..}, at: [] tcp_v6_rcv+0x30e/0x76e
> [ipv6]
The tcp_v6_rcv() code
From: Ben Greear <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 14:55:17 -0700
> The skb_bond method assigns skb->dev when it does the 'keep',
> but the VLAN code immediately over-writes the skb->dev when
> searching for the vlan device.
>
> What is the purpose of assinging skb->dev to the master dev
From: James Morris <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 17:00:15 -0400 (EDT)
> The patch below fixes a problem in the iptables SECMARK target, where the
> user-supplied 'selctx' string may not be nul-terminated.
Applied, thanks James.
-
To unsubscribe from this list: send the line "unsubsc
From: Steve Wise <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 13:28:49 -0500
> Dave/Roland, is this patchset about ready to go?
All 3 patches applied, thanks Steve.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
From: Wei Yongjun <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 07:40:37 -0400
> I have changed my patch with your advice and it looks more effective.
...
> Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]>
This looks very nice, patch applied. Thank you very much.
-
To unsubscribe from this list: sen
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Fri, 28 Jul 2006 18:25:34 +0900 (JST)
> Changesets, on top of 2.6.18-rc2, are available on
> branch "addr-lifetime-20060728b" at:
> git://git.skbuff.net/gitroot/yoshfuji/linux-2.6.18-rc2-addr-lifetime
Pulled, thank you very much.
-
To unsubscr
On Sun, Jul 30, 2006 at 03:44:16PM -0700, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Sat, 29 Jul 2006 14:33:25 +1000
>
> > [IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
> >
> > The current users of ip6_dst_lookup can be divided into two classes:
> >
> > 1) The call
On Tue, 25 Jul 2006 09:20:06 -0700 Auke Kok wrote:
> Alan Stern wrote:
> > During a Power Management session at the Ottawa Linux Symposium, it was
> > generally agreed that network interface drivers ought to automatically
> > suspend their devices (if possible) whenever:
> >
> > (1) The inter
On Sat, 29 Jul 2006, Masahide NAKAMURA wrote:
> + remote = (xfrm[i]->type->remote_addr) ?
> + (struct
> in6_addr*)xfrm[i]->type->remote_addr(xfrm[i], (xfrm_address_t *)remote):
> + (struct in6_addr*)&xfrm[i]->id.daddr;
>
On Sat, 29 Jul 2006, Masahide NAKAMURA wrote:
> - hdr_len = ip6_find_1stfragopt(skb, &prevhdr);
> + if (x->type->place_find)
> + hdr_len = x->type->place_find(x, skb, &prevhdr);
> + else
> + hdr_len = ip6_find_1stfragopt(s
On Thu, 2006-07-20 at 14:56 +1000, Russell Stuart wrote:
> On Wed, 2006-07-19 at 16:50 +0200, Patrick McHardy wrote:
> > Please excuse my silence, I was travelling and am still catching up
> > with my mails.
>
> Sorry. Had I realised you were busy I would of
> waited.
>
> > > - As it stands, it
From: Sam Ravnborg <[EMAIL PROTECTED]>
Date: Mon, 31 Jul 2006 00:45:43 +0200
> >From a pure eye-candy perspective it would be nice to use same format
> all over.
> >From Documentation/SubmittingPatches:
> --
> 12) The canonical patch format
>
> The canonical patch subject line is:
From: "Jesper Juhl" <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 23:51:20 +0200
> Looks ok to me.
I've applied James's version of the fix, thanks everyone.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http:
Kyle McMartin wrote:
parisc-linux
merged Francois' tulip workqueue patch some time ago, and have been
running with it since without issue. This defers the tulip_select_media
work to process context, and so should be less of an issue.
Good to hear. That's definitely my preference for future dir
Andrew Morton wrote:
hm. A couple of those patches have been futzing around in -mm for over a
year and have been nacked by Jeff and are a regular source of grumpygrams.
I've been sitting on them in the pathetic hope that someone will one day
get down and address the bugs which they fix in an a
From: Toralf Förster <[EMAIL PROTECTED]>
Date: Sat, 29 Jul 2006 20:55:11 +0200
> Subject: linux- 2.6.17.7 undefined reference to `alloc_ltalkdev'
Bug is that appletalk is built modular, which is where
alloc_ltalkdev is exported from, but we allow users of
this symbol, such as the cops driver, to
For stable only:
On Tue, Jul 18, 2006 at 04:13:29AM +1000, herbert wrote:
>
> Here is a second attempt:
>
> [NET]: Update frag_list in pskb_trim
Unfortunately there was a bug in the fix which is now fixed. I presume
this hasn't been included yet so I'm simply regenerating the whole patch.
Let
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 29 Jul 2006 21:45:25 +1000
> [NET]: Fix ___pskb_trim when entire frag_list needs dropping
>
> When the trim point is within the head and there is no paged data,
> ___pskb_trim fails to drop the first element in the frag_list.
> This patch fixes this
From: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Sat, 29 Jul 2006 11:45:45 +0400
> Header doesn't use anything from atomic.h.
> It fixes headers_check warning:
>
> include/linux/netfilter_bridge.h requires asm/atomic.h, which does not exist
>
> Compile tested on
> alpha arm i386-up sparc
On Sun, Jul 30, 2006 at 03:28:46PM -0700, David Miller wrote:
> From: "Ilpo J?rvinen" <[EMAIL PROTECTED]>
> Date: Sun, 30 Jul 2006 14:01:09 +0300 (EEST)
>
> >[TCP] FRTO: summary here
>
> This looks perfectly fine.
Looking 100 commits back or so it is obvious we have two distinct
notations:
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 29 Jul 2006 14:33:25 +1000
> [IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
>
> The current users of ip6_dst_lookup can be divided into two classes:
>
> 1) The caller holds no locks and is in user-context (UDP).
> 2) The caller does not want
From: James Morris <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 18:20:46 -0400 (EDT)
> The overall kernel config is getting very messed up because of all of
> these selects.
The idea is that the user should be shielded from having to know what
random kernel internal subsystem is necessary in order
From: Krzysztof Halasa <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 18:40:04 +0200
> Do the semantics (I'm not talking about bugs) allow skb passed
> to dev->hard_header() (if defined) and then to dev->hard_start_xmit()
> to have less link layer header space than dev->hard_header_len?
>
> I.e., is
From: "Ilpo Järvinen" <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 14:01:09 +0300 (EEST)
>[TCP] FRTO: summary here
This looks perfectly fine.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ker
On Sat, 29 Jul 2006, Masahide NAKAMURA wrote:
> +config IPV6_MIP6
> + bool "IPv6: Mobility (EXPERIMENTAL)"
> + depends on IPV6 && EXPERIMENTAL
> + select XFRM
> + select XFRM_ADVANCED
Why 'select' here instead of 'depends on'?
The overall kernel config is getting very messed up b
On Sat, 29 Jul 2006, Masahide NAKAMURA wrote:
> This option is for enhanced transformation features and it will be used by
> Mobile IPv6.
> Based on MIPL2 kernel patch.
> ---
> net/xfrm/Kconfig |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/net/xfrm/Kconfig
Hello,
I recently aquired a Lenovo (IBM) T60 with a e1000 network card. I
experience high latency with this networkcard: Pings last upto 1 second
where the ping should be around 25 ms. I googled a bit and found the
following:
- Enable NAPI, which didn't worked for me.
64 bytes from 192.16
On 30/07/06, James Morris <[EMAIL PROTECTED]> wrote:
On Sun, 30 Jul 2006, Stephen Hemminger wrote:
> On Sun, 30 Jul 2006 21:38:02 +0200
> Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> > There's an obvious memory leak in net/ipv4/tcp_probe.c::tcpprobe_read()
> > We are not freeing 'tbuf' on error.
>
On Sun, 30 Jul 2006, Stephen Hemminger wrote:
> On Sun, 30 Jul 2006 21:38:02 +0200
> Jesper Juhl <[EMAIL PROTECTED]> wrote:
>
> > There's an obvious memory leak in net/ipv4/tcp_probe.c::tcpprobe_read()
> > We are not freeing 'tbuf' on error.
> > Patch below fixes that.
> >
> >
> > Signed-off-by
On Sun, 30 Jul 2006 21:38:02 +0200
Jesper Juhl <[EMAIL PROTECTED]> wrote:
> There's an obvious memory leak in net/ipv4/tcp_probe.c::tcpprobe_read()
> We are not freeing 'tbuf' on error.
> Patch below fixes that.
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Agreed, thanks for catching it.
Hi all,
I have some questions regarding Linux TCP in the presence of delays or
packet drops. It is somehow long mail, but the questions are two or
three, just wanted to provide a detailed information so that the problem
is clear. thanx for the patience!!
Best regards,
Oumer
Note that for th
There's an obvious memory leak in net/ipv4/tcp_probe.c::tcpprobe_read()
We are not freeing 'tbuf' on error.
Patch below fixes that.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
net/ipv4/tcp_probe.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.18-rc3-orig/net
On Sun, Jul 30, 2006 at 11:35:32AM -0700, Andrew Morton wrote:
> hm. A couple of those patches have been futzing around in -mm for over a
> year and have been nacked by Jeff and are a regular source of grumpygrams.
> I've been sitting on them in the pathetic hope that someone will one day
> get d
The driver wrongly claimed I/O ports at an address returned by pci_iomap() --
even if it was passed an MMIO address. Fix this by claiming/releasing all PCI
resources in the PCI driver probe/remove handlers instead and get rid of the
must_free_region flag weirdness (why would Cardbus claim anythi
On Sun, 30 Jul 2006 12:56:07 -0400
Kyle McMartin <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 29, 2006 at 06:43:39PM -0600, Grant Grundler wrote:
> > I just wanted to warn that some of the changes are already in akpm
> > 's tree (-mm).
> > Becuase off hand I've forgotten which ones, would it be better
On Sat, Jul 29, 2006 at 06:43:39PM -0600, Grant Grundler wrote:
> I just wanted to warn that some of the changes are already in akpm
> 's tree (-mm).
> Becuase off hand I've forgotten which ones, would it be better to
> diff against -mm instead?
tulip-fix-shutdown-dma-irq-race.patch
tulip: fix s
Hello Alexey,
Can you clarify this for me, please?
Do the semantics (I'm not talking about bugs) allow skb passed
to dev->hard_header() (if defined) and then to dev->hard_start_xmit()
to have less link layer header space than dev->hard_header_len?
I.e., is dev->hard_header_len only advisory?
--
Hello,
My network has several IPv6 addresses and they don't route between
themselves, due to the current source address selection it means that
many times the network is simply not operational since Linux will choose
an address for a different network than targeted for the connection.
I have seen
On Sun, 23 Jul 2006, Krzysztof Oledzki wrote:
On Fri, 26 May 2006, Stephen Hemminger wrote:
Please give this a try, it rearranges the transmit buffer management,
and may avoid issues with partial completions causing SKB reuse.
Plase excuse me, I overlooked this patch. Anyway, it seems
Hi,
> On the other hand, if a ND daemon loose the synchronization, it is
> unpredicable, I guess.
What do you mean by synchronization in this context? My idea was to
keep the ND state machine inside the kernel, and instead have the
daemon be reactive. That means it would send messages on beh
Hi,
I have read through http://linux.yyz.us/patch-format.html, which uses
$subsystem as prefix for summary. Could you please clarify what is
appropriate "prefix" for the actual summary in a case where patch touches
only a part of a subsystem, that is in my case, FRTO. Should the
subsystem be T
On Sat, 2006-07-29 at 11:45 +0400, Alexey Dobriyan wrote:
> Header doesn't use anything from atomic.h.
> It fixes headers_check warning:
>
> include/linux/netfilter_bridge.h requires asm/atomic.h, which does not exist
>
> Compile tested on
> alpha arm i386-up sparcsparc64-up x86_64
>
This patch contains the following possible cleanups:
- make the following needlessly global functions static:
- net/netfilter/nf_conntrack_core.c: nf_conntrack_register_cache()
- net/netfilter/nf_conntrack_core.c: nf_conntrack_unregister_cache()
- net/netfilter/nf_conntrack_core.c: __nf_connt
hello michael,
sending bugreport to netdev.
On Sun, 30 Jul 2006, Michael Banck wrote:
> Package: linux-2.6
> Version: 2.6.17-4
>
> after hibernate, my 3Com Corporation 3c556 Hurricane CardBus [Cyclone]
> (rev 10) (3c59x driver) fails to come back up.
>
> This is written on the console/xterm:
>
Nicholas Miell wrote:
> [...] and was wondering
> if you were familiar with the Solaris port APIs* and,
I wasn't.
> if so, you could
> please comment on how your proposed event channels are different/better.
There indeed is not much difference. The differences are in the
details. The way thos
Lamarque Souza wrote:
> I have this problem since I first tried to use suspend. The
> first kernel I
> tried was 2.6.13 I guess. Since that time I reload the
> driver, then I do
> not know if it works with kernel 2.6.14, 2.6.15 or 2.6.16
> without reloading.
>
I just tried SOFTWARE_SUSPEND
58 matches
Mail list logo