On Wed, 29 Nov 2006 08:36:09 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 27, 2006 at 10:24:55AM -0800, Stephen Hemminger wrote:
> > On Fri, 24 Nov 2006 01:17:31 +0100
> > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, Nov 23, 2006 at 02:17:03AM -0800, Andrew Morton wrote:
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> =
> [ INFO: possible irq lock inversion dependency detected ]
> 2.6.19-rc6 #4
> -
> nc/1854 just changed the state of lock:
> (af_callback_k
On Mon, Nov 27, 2006 at 10:24:55AM -0800, Stephen Hemminger wrote:
> On Fri, 24 Nov 2006 01:17:31 +0100
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Nov 23, 2006 at 02:17:03AM -0800, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.19-rc5-mm2:
> > >...
> > > +chelsio-22-driver.patch
On 29-11-2006 05:25, David Miller wrote:
...
> commit 93e3a20d6c67a09b867431e7d5b3e7bc97154fab
> Author: David S. Miller <[EMAIL PROTECTED]>
> Date: Tue Nov 28 20:24:10 2006 -0800
>
> [NET]: Fix MAX_HEADER setting.
>
> MAX_HEADER is either set to LL_MAX_HEADER or LL_MAX_HEADER + 48,
Berck E. Nash wrote:
I've been having problems with the sky2 ethernet driver from the very
beginning. I have read the following:
http://marc.theaimsgroup.com/?l=linux-netdev&m=116384918914761&w=2
And the bug described still exists for me. I'm running 2.6.19-rc6-mm1.
That motherboard has dua
On Tue, Nov 28, 2006 at 09:04:16PM -0800, David Miller wrote:
>
> > Definitely. I'm not sure whether 48 is enough even for recursive
> > tunnels. This should really just be a hint. It's OK to spend a
> > bit of time reallocating skb's if it's too small, but it's not OK
> > to die.
>
> The recur
This seems to be a pretty clean solution to a real problem.
Ultimately I would like to see IPVS move into the forward chain.
This seems to be a nice way to explore that, without breaking
any existing setups.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
[IPVS]
On Tue, Nov 28, 2006 at 09:26:52PM +0100, Daniel Lezcano wrote:
> Eric W. Biederman wrote:
> > I do not want to get into a big debate on the merits of various
> > techniques at this time. We seem to be in basic agreement
> > about what we are talking about.
> >
> > There is one thing I think
On Tue, Nov 28, 2006 at 02:50:03PM -0700, Eric W. Biederman wrote:
> Daniel Lezcano <[EMAIL PROTECTED]> writes:
>
> > Eric W. Biederman wrote:
> >> I do not want to get into a big debate on the merits of various
> >> techniques at this time. We seem to be in basic agreement
> >> about what we are
On Sat, Nov 18, 2006 at 02:25:27PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Sat, Nov 18, 2006 at 12:21:34PM +0100, maximilian attems ([EMAIL
> PROTECTED]) wrote:
> > > > > > > > > Bug was filled against 2.6.17-9, but was fixed in recent git
> > > > > > > > > (2.6.19-rc3), probably
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 29 Nov 2006 15:56:57 +1100
> David Miller <[EMAIL PROTECTED]> wrote:
> >
> > Longer term this is really messy, we should handle this some
> > other way.
>
> Definitely. I'm not sure whether 48 is enough even for recursive
> tunnels. This should r
I've been having problems with the sky2 ethernet driver from the very
beginning. I have read the following:
http://marc.theaimsgroup.com/?l=linux-netdev&m=116384918914761&w=2
And the bug described still exists for me. I'm running 2.6.19-rc6-mm1.
The only relevant console output:
[55022.35321
David Miller <[EMAIL PROTECTED]> wrote:
>
> Longer term this is really messy, we should handle this some
> other way.
Definitely. I'm not sure whether 48 is enough even for recursive
tunnels. This should really just be a hint. It's OK to spend a
bit of time reallocating skb's if it's too small
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 29 Nov 2006 15:38:29 +1100
> David Miller <[EMAIL PROTECTED]> wrote:
> >
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 9264139..95e86ac 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
On Tue, Nov 28, 2006 at 05:32:59PM +, Ralf Baechle wrote:
> Confusingly NET_PCI is also set for for non-PCI EISA configurations where
> building this driver will result in a build error due to a reference to
> pci_release_regions.
>
> While at it, remove the EXPERIMENTAL - in all its uglyness
David Miller <[EMAIL PROTECTED]> wrote:
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 9264139..95e86ac 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -94,7 +94,9 @@ #endif
> #endif
>
> #if !defined(CONFIG_NET_IPIP) && \
> -!def
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 29 Nov 2006 03:28:25 +0100
> [NETFILTER]: ipt_REJECT: fix memory corruption
>
> On devices with hard_header_len > LL_MAX_HEADER ip_route_me_harder()
> reallocates the skb, leading to memory corruption when using the stale
> tcph pointer to upda
Herbert Xu [EMAIL PROTECTED] wrote:
I think there are two problems here:
1) The first time we hit the check rate_last is zero. We should simply
proceed with the redirect rather than treating this as a jiffies value.
2) When a dst is so old that the jiffies have wrapped around. I'm
not sure w
Krzysztof Halasa wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>
>>It might be the case that your network device has a
>>hard_header_len > LL_MAX_HEADER, which could trigger
>>a corruption.
>
>
> Hmm... GRE tunnels add 24 bytes... I just noticed the following code in
> include/linux/ne
Patrick McHardy <[EMAIL PROTECTED]> writes:
> It might be the case that your network device has a
> hard_header_len > LL_MAX_HEADER, which could trigger
> a corruption.
Hmm... GRE tunnels add 24 bytes... I just noticed the following code in
include/linux/netdevice.h:
/*
* Compute the worst
On Thu, Nov 23, 2006 at 12:18:09PM +1100, David Chinner wrote:
> On Wed, Nov 22, 2006 at 01:58:11PM +0100, Jesper Juhl wrote:
> >
> > Attached are two files. The one named stack_overflows.txt.gz contains
> > one instance of each unique stack overflow + trace that I've got. The
> > other file name
Make ip_vs_sync.c <= 80col wide
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/net/ipv4/ipvs/ip_vs_sync.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c 2006-11-29 09:53:51.0
+0900
+++ linux-2.6/net/ip
On Tue, Nov 28, 2006 at 10:35:01AM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 28 Nov 2006, Horms wrote:
>
> > Dean Manners notices that when an IPVS synchonisation daemons are
> > started the system load slowly climbs up to 1. This seems to be related
> > to the call to ssleep(1
This update gets most of the drivers building again, with the notable
exception of the rt2x00 drivers... There are lots of updates from
Michael Wu to the p54 driver as well. Also, a patch from Michael
Buesch that fixes a hwcrypto issue, but incidentally drops support
for rev 3 firmware from the d
On Tue, 2006-11-28 at 15:43 -0800, David Miller wrote:
> At least in theory the atomic + any necessary memory barriers
> would be cheaper than the extra PIO read we need otherwise.
Yes, IO reads are generally the worst case scenarios even on machines
with fairly slow locks.
Ben.
-
To unsubscri
On Tue, 28 Nov 2006 15:35:31 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
>
> Andrew, I'm fine with these three patches, specifically:
>
> [PATCH] dont insert pipe dentries into dentry_hashtable.
> [PATCH] [DCACHE] : avoid RCU for never hashed dentries
> [PATCH] [NET] dont insert socket d
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Wed, 29 Nov 2006 09:57:24 +1100
>
> > This looks mostly fine.
> >
> > I was thinking about the lockless stuff, and I wonder if there
> > is a clever way you can get it back down to one PIO on the
> > GREG_STAT register.
> >
> > I think you'
Andrew, I'm fine with these three patches, specifically:
[PATCH] dont insert pipe dentries into dentry_hashtable.
[PATCH] [DCACHE] : avoid RCU for never hashed dentries
[PATCH] [NET] dont insert socket dentries into dentry_hashtable.
Could you toss them into -mm if you haven't already? This
mak
From: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Wed, 22 Nov 2006 00:22:51 +0300
> [CCing netdev, bug in pktgen]
>
> [build modular pktgen]
> while true; do modprobe pktgen && rmmod pktgen; done
>
> BUG: warning at fs/proc/generic.c:732/remove_proc_entry()
>[] remove_pro
> This looks mostly fine.
>
> I was thinking about the lockless stuff, and I wonder if there
> is a clever way you can get it back down to one PIO on the
> GREG_STAT register.
>
> I think you'd need to have the ->poll() clear gp->status, then
> do a smp_wb(), right before it re-enables interrupt
From: "Eric Lemoine" <[EMAIL PROTECTED]>
Date: Tue, 14 Nov 2006 22:54:40 +0100
> On 11/14/06, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Eric Lemoine" <[EMAIL PROTECTED]>
> > Date: Tue, 14 Nov 2006 08:28:42 +0100
> >
> > > because it makes it explicit that only bits 0 through 6 are taken i
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 31 Oct 2006 17:30:28 -0800 (PST)
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Tue, 31 Oct 2006 16:10:07 -0800
>
> > On Tue, 31 Oct 2006 15:25:16 -0800
> > "Xiaoliang (David) Wei" <[EMAIL PROTECTED]> wrote:
> >
> > > It seems that the def
Daniel Lezcano <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> I do not want to get into a big debate on the merits of various
>> techniques at this time. We seem to be in basic agreement
>> about what we are talking about.
>>
>> There is one thing I think we can all agree upon.
>> - Ev
Krzysztof Halasa wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>>How sure are you about this? I can see nothing wrong with that
>>commit and can't reproduce the slab corruption. Please post
>>the rule that triggers this.
>
>
> 99% sure. Past this commit I get corruptions after 5 minutes
Patrick McHardy <[EMAIL PROTECTED]> writes:
>> The following commit breaks ipt_REJECT on my machine. Tested with latest
>> 2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
>> All details available on request, of course.
>>
>> commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
>
>
On Tuesday 28 November 2006 21:39, Daniel Drake wrote:
> Hi,
>
> I'm interested in porting the ar5k driver to Linux after the recent SFLC
> conclusions on the legal status. However, the hardware I have here
> appears to be unsupported by ar5k:
>
> 01:04.0 0200: 168c:001a (rev 01)
> Subsys
Hi,
I'm interested in porting the ar5k driver to Linux after the recent SFLC
conclusions on the legal status. However, the hardware I have here
appears to be unsupported by ar5k:
01:04.0 0200: 168c:001a (rev 01)
Subsystem: 168c:2052
01:04.0 Ethernet controller: Atheros Communications, In
On Tue, 28 Nov 2006 10:03:31 -0800
"Felix Marti" <[EMAIL PROTECTED]> wrote:
> Andrew:
> > On Tue, 28 Nov 2006 00:17:38 +0100
> > Francois Romieu <[EMAIL PROTECTED]> wrote:
> >
> > > Stephen Hemminger <[EMAIL PROTECTED]> :
> > > > This patch is experimental, it applies after the earlier 6 chelsio
>
Eric W. Biederman wrote:
> I do not want to get into a big debate on the merits of various
> techniques at this time. We seem to be in basic agreement
> about what we are talking about.
>
> There is one thing I think we can all agree upon.
> - Everything except isolation at the network device/L2
After a succesfull authentication and association the matching retry counter
must be reset to 0.
Failure to do so will result in failure to authenticate after the interface
has been deauthenticated. This does not always happen after the first
deauthentication, but after the interface has been sever
Krzysztof Halasa wrote:
> Hi,
>
> The following commit breaks ipt_REJECT on my machine. Tested with latest
> 2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
> All details available on request, of course.
>
> commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
How sure are you abo
The following changes since commit 6c025cfcd2904990ba9acda820fda1fe02ee267f:
John W. Linville:
Merge branch 'upstream-fixes' into upstream
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
Arnaldo Carvalho de Melo:
The following changes since commit 0579e303553655245e8a6616bd8b4428b07d63a2:
Linus Torvalds:
Merge branch 'for-linus' of git://git.kernel.org/.../drzeus/mmc
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-fixes
Joh
Hi folks,
I have been tracking down a strange problem, and have a simple
"reproduce-by" and was looking for opinions from those better-versed in
the kernel networking code. Basically, it is possible to get a system
into a state where it responds to ARP requests even though no interface
has the addr
On Tue, Nov 28, 2006 at 11:13:00AM -0800, David Miller ([EMAIL PROTECTED])
wrote:
> From: Evgeniy Polyakov <[EMAIL PROTECTED]>
> Date: Tue, 28 Nov 2006 12:16:02 +0300
>
> > Although ukevent has pointer embedded, it is unioned with u64, so there
> > should be no problems until 128 bit arch appeare
On Tue, Nov 14, 2006 at 08:29:26PM -0500, John W. Linville wrote:
> The following changes since commit 0579e303553655245e8a6616bd8b4428b07d63a2:
> Linus Torvalds:
> Merge branch 'for-linus' of git://git.kernel.org/.../drzeus/mmc
>
> are found in the git repository at:
>
> git://git.ke
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Tue, 28 Nov 2006 12:16:02 +0300
> Although ukevent has pointer embedded, it is unioned with u64, so there
> should be no problems until 128 bit arch appeared, which likely will not
> happen soon. There is also unused in kevent posix timers patch
> '
On Tue, Nov 14, 2006 at 08:31:12PM -0500, John W. Linville wrote:
> The following changes since commit 4c5d3c72166676663c3917839a030b86fa758b23:
> John W. Linville:
> Merge branch 'upstream-fixes' into upstream
>
> are found in the git repository at:
>
> git://git.kernel.org/pub/scm/l
On Tue, 28 Nov 2006 08:04:40 -0800 (PST)
"Amit S. Kale" <[EMAIL PROTECTED]> wrote:
> Hi Stephen,
>
>
> > > > you need explicit bounce buffers. If you can't DMA from unaligned
> address,
> > > > > the write a small routine to copy the skb to a new one.
> > > >
> > > >
> > > > The hardware suppo
Hi,
The following commit breaks ipt_REJECT on my machine. Tested with latest
2.6.19rc*, found with git-bisect. i386, gcc-4.1.1, the usual stuff.
All details available on request, of course.
commit 9d02002d2dc2c7423e5891b97727fde4d667adf1
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon Oct
Andrew:
> On Tue, 28 Nov 2006 00:17:38 +0100
> Francois Romieu <[EMAIL PROTECTED]> wrote:
>
> > Stephen Hemminger <[EMAIL PROTECTED]> :
> > > This patch is experimental, it applies after the earlier 6 chelsio
cleanup
> > > patches. Tested on a pair of T210 board's.
> >
> > The whole serie is store
On Tue, Nov 28, 2006 at 09:51:57AM -0700, Eric W. Biederman wrote:
>
> I do not want to get into a big debate on the merits of various
> techniques at this time. We seem to be in basic agreement
> about what we are talking about.
>
> There is one thing I think we can all agree upon.
> - Everythi
Confusingly NET_PCI is also set for for non-PCI EISA configurations where
building this driver will result in a build error due to a reference to
pci_release_regions.
While at it, remove the EXPERIMENTAL - in all its uglyness and despite
the sincerest attempts of the buggy hardware the driver is k
I do not want to get into a big debate on the merits of various
techniques at this time. We seem to be in basic agreement
about what we are talking about.
There is one thing I think we can all agree upon.
- Everything except isolation at the network device/L2 layer, does not
allow guests to ha
Hi Stephen,
> > you need explicit bounce buffers. If you can't DMA from unaligned
address,
> > > the write a small routine to copy the skb to a new one.
> >
> >
> > The hardware supports DMA into 35 bit addresses. The intent is to
> > enable DMA into addresses upto 32G.
> >
>
> You should th
On Monday 27 November 2006 21:37, Larry Finger wrote:
> From: Michael Buesch <[EMAIL PROTECTED]>
>
> In the scan section of ieee80211softmac, network transmits are disabled.
> When SoftMAC re-enables transmits, it may override the wishes of a driver
> that may have very good reasons for disabling
Eric W. Biederman wrote:
[ snip ]
The packets arrive to the real device and go through the routes
engine. From this point, the used route is enough to know to which
container the traffic can go and the sockets subset assigned to the
container.
Note this has potentially the highest overhead o
=
[ INFO: possible irq lock inversion dependency detected ]
2.6.19-rc6 #4
-
nc/1854 just changed the state of lock:
(af_callback_keys + sk->sk_family#2){-.-?}, at: []
sock_def_error_re
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > This patch moves the EXPORT_SYMBOL's from net/rxrpc/rxrpc_syms.c to the
> > > files with the actual functions.
> >
> > You can if you like. Can you slap a blank line before each EXPORT_SYMBOL()
> > though please?
>
> Updated patch below.
Acked-By:
On Mon, Nov 27, 2006 at 11:12:21AM -0800, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >It just sets hrtimer with abs time and sleeps - it can achieve the same
> >goals using similar to wait_event() mechanism.
>
> I don't follow. Of course it is somehow possible to wait
On Mon, Nov 27, 2006 at 11:43:46AM -0800, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >It _IS_ how previous interface worked.
> >
> > EXACTLY!
>
> No, the old interface committed everything not only up to a given index.
> This is the huge difference which makes or
On Mon, Nov 27, 2006 at 10:23:39AM -0800, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> >
> >With provided patch it is possible to wakeup 'for-free' - just call
> >kevent_ctl(ready) with zero number of ready events, so thread will be
> >awakened if it was in poll(kevent_fd)
On Mon, Nov 27, 2006 at 10:20:50AM -0800, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> sigev_value is a union and the largest element is a pointer. So,
> transporting the pointer value is sufficient and it should be passed up
> to the user in the ptr member of struct ukevent.
That is where I've
> On my Cell blade this failed on the latest build (be0646). Running with
> the changes to sungem_phy does not allow the interfaces to ping anything.
> I went back to the original and everything works again. All I did was
> change sungem_phy and force it to be reloaded, let me know if I missed a
On Mon, Nov 27, 2006 at 10:49:55AM -0800, David Miller ([EMAIL PROTECTED])
wrote:
> From: Ulrich Drepper <[EMAIL PROTECTED]>
> Date: Mon, 27 Nov 2006 10:36:06 -0800
>
> > David Miller wrote:
> > > Now we'll have to have a compat layer for 32-bit/64-bit environments
> > > thanks to POSIX timers, w
Hello,
On Tue, 28 Nov 2006, Horms wrote:
> Dean Manners notices that when an IPVS synchonisation daemons are
> started the system load slowly climbs up to 1. This seems to be related
> to the call to ssleep(1) (aka msleep(1000) in the main loop. Replacing
> this with a call to msleep_int
66 matches
Mail list logo
