itionally makes sure
> each timer is only initialized once.
>
> [NET]: gen_estimator: fix locking and timer related bugs
>
> As noticed by Jarek Poplawski <[EMAIL PROTECTED]>, the timer removal in
> gen_kill_estimator races with the timer function rearming the timer.
>
On Wed, Jun 27, 2007 at 02:10:13PM +0200, Jarek Poplawski wrote:
...
- > So if it's not only about kindness, feel free to do it
+ > So if it's only about kindness, feel free to do it
Sorry!
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe netdev" i
On Wed, Jun 27, 2007 at 01:44:08PM +0200, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> >On 25-06-2007 11:28, Patrick McHardy wrote:
> >...
> >
> >>It is. This patch I had originally planned for 2.6.23 switches HTB
> >>to the generic esti
On 25-06-2007 11:28, Patrick McHardy wrote:
...
> It is. This patch I had originally planned for 2.6.23 switches HTB
> to the generic estimator, which shouldn't suffer from this.
BTW, maybe I look at this too short, but is this del_timer()
in gen_kill_estimator() enough? I cannot see nothing again
(second try! sorry)
On 27-06-2007 10:36, Jeff Garzik wrote:
> [EMAIL PROTECTED] wrote:
>> Hello All,
>>
>> We have been experimenting a couple of interface hangs with the 8139cp
>> driver. It appears that the tx buffer stops transmitting and never starts
>> up again in some yet unknown conditions
Jean-Baptiste Vignaud <[EMAIL PROTECTED]>,
"marcin.slusarz" <[EMAIL PROTECTED]>,
shemminger <[EMAIL PROTECTED]>
Subject: Re: [PATCH] 8139cp dev->tx_timeout
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
On 27-06-2007 10:36, Jeff Garzik wrote:
> [EMAIL PROTECTE
On Tue, Jun 26, 2007 at 04:24:07PM +0200, Jean-Baptiste Vignaud wrote:
> Hello, i have a very similar problem with 2.6.21 also;
>
> 2 3com NICs and they are failling randomly.
>
> The kernel is a basic fedora 7 kernel (2.6.21-1.3228.fc7)
> I found a bug report and added details here :
> https://
ix
> > the problem that was reported.
>
> OK, thanks. Please don't mail people separately!
>
> I queued this up with a null changelog for now.
>
I pasted here this queued version - only the changelog is added.
Regards,
Jarek P.
----
On Tue, Jun 26, 2007 at 08:10:17AM +0200, Marcin Ślusarz wrote:
...
> I reproduced it on minimal config:
...
Hm... This method is usable if you can find such minimal config
with which the bug cannot be reproduced. Then you can add more
until the bug is back. Of course, this takes time...
We know
On Fri, Jun 22, 2007 at 10:56:44AM +0200, Marcin Ślusarz wrote:
...
> When I disable on-board network card in BIOS (controlled by skge)
> ne2k-pci card is still locking up. So I think it's strictly ne2k-pci
> card bug. I made some tests and I know how to reproduce it fast (on my
> machine) - just m
On Mon, Jun 18, 2007 at 08:10:00AM -0700, Stephen Hemminger wrote:
> On Mon, 18 Jun 2007 13:08:49 +0200
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > On 16-06-2007 23:35, Marcin .lusarz wrote:
> > > hi
> > > after upgrading kernel from 2.6.20 to 2.6.21.
On Mon, Jun 18, 2007 at 08:10:00AM -0700, Stephen Hemminger wrote:
> On Mon, 18 Jun 2007 13:08:49 +0200
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
...
> > It looks like skge driver enables different device than probbed.
> > Maybe you've something old/wrong ab
On 16-06-2007 23:35, Marcin .lusarz wrote:
> hi
> after upgrading kernel from 2.6.20 to 2.6.21.3 i'm experiencing really
> strange problem - my _both_ network cards dies after random uptime -
> sometimes it's a few minutes, sometimes hours, sometimes it does not
> happen for a couple of days...
> t
On Tue, Jun 12, 2007 at 01:02:33PM +0200, Jarek Poplawski wrote:
...
> Of course such a problem should preferably be fixed by somebody who
> knows the code (alas I don't know netconsole), to be sure all needed
> cancels are still done after this change. I hope Jason's patch i
On Tue, May 29, 2007 at 12:56:28AM -0700, Andrew Morton wrote:
> On Sat, 26 May 2007 17:40:12 +0200 Folkert van Heusden <[EMAIL PROTECTED]>
> wrote:
>
> > When trying to remove the netconsole module, I got the following kernel
> > output after a while (couple of minutes iirc):
> >
> > [525720.11
On Tue, May 15, 2007 at 11:17:51PM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Wed, 16 May 2007 08:17:32 +0200
>
> > BTW - I think some patch on vlan cannot do any harm (at
> > least like this previous of mine - with only ppp
> >
On Tue, May 15, 2007 at 10:47:25PM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Wed, 16 May 2007 07:40:00 +0200
>
> > After initializing dev->_xmit_lock register_netdevice()
> > sets lockdep class according to dev->type.
>
On Tue, May 15, 2007 at 12:49:47PM +0400, Yuriy N. Shkandybin wrote:
> I've patched 2.6.22-rc1 and there was no warnings from lock debugger.
>
So, you mean only this one patch - without previous vlan patch?
Very interesting...
Thanks once more,
Jarek P.
-
To unsubscribe from this list: send the
uot;Yuriy N. Shkandybin" <[EMAIL PROTECTED]>
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp 2.6.22-/net/core/dev.c 2.6.22/net/core/dev.c
--- 2.6.22-/net/core/dev.c 2007-05-14 20:26:16.0 +0200
+++ 2.6.22/net/core/dev.c 2007-05-16 07:35:22.0
On Tue, May 15, 2007 at 12:49:47PM +0400, Yuriy N. Shkandybin wrote:
> I've patched 2.6.22-rc1 and there was no warnings from lock debugger.
>
> Jura
Many thanks, Jura!
It seems reality is sometimes merciful...
On the other hand I wonder, how all this could stay so long:
a configuration similar
On Sun, May 13, 2007 at 11:39:37PM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Mon, 14 May 2007 08:07:00 +0200
>
> > After sending this patch I was a little confused, when next
> > lockdep warning report appeared, and I thought - si
On Mon, May 14, 2007 at 10:08:29AM +0200, Jarek Poplawski wrote:
> On Mon, May 14, 2007 at 09:28:45AM +0200, Jarek Poplawski wrote:
> > On Sun, May 13, 2007 at 11:39:37PM -0700, David Miller wrote:
> ...
> > > For each unique netdev type, use a different locking class.
>
On Mon, May 14, 2007 at 02:18:31AM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Mon, 14 May 2007 09:28:45 +0200
>
> > Yes, this is very good idea, and I wonder, why you didn't try
> > this yourself (after my "ignore").
On Mon, May 14, 2007 at 09:28:45AM +0200, Jarek Poplawski wrote:
> On Sun, May 13, 2007 at 11:39:37PM -0700, David Miller wrote:
...
> > For each unique netdev type, use a different locking class.
> >
> > That will fix this forever, anything else is a situation specific
&
On Sun, May 13, 2007 at 11:39:37PM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Mon, 14 May 2007 08:07:00 +0200
>
> > After sending this patch I was a little confused, when next
> > lockdep warning report appeared, and I thought - si
On Fri, May 11, 2007 at 02:12:25PM -0700, Andrew Morton wrote:
> On Fri, 11 May 2007 14:03:09 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Jeff Garzik <[EMAIL PROTECTED]>
> > Date: Fri, 11 May 2007 16:57:19 -0400
> >
> > > applied
> >
> > I was under the impression that this
parts of configs or at least
"ip link" output.
Regards,
Jarek P.
--->
This patch's aim is to let lockdep see ppp dev->_xmit_lock as
different from others, after register_netdev inits this lock.
Reported & tested by: "Yuriy N. Shkandybin" <[EMAIL PROTECTED]>
C
On Thu, May 10, 2007 at 10:03:23AM +0400, Yuriy N. Shkandybin wrote:
> Yes, there is no real lockup with pppoe
> ll repeat my configuration:
> vpn (pptp(mostly)+pppoe) concentrator
> PPPoE provided through 802.1q
> +OSPF (quagga)
I think, it's a little too general... Probably at least
ifconfig and
On Thu, May 10, 2007 at 12:06:09AM +0400, Yuriy N. Shkandybin wrote:
> After applying this patch i've got this:
>
> ===
> [ INFO: possible circular locking dependency detected ]
> 2.6.21-gentoo #2
> ---
On Wed, May 09, 2007 at 02:32:24AM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Wed, 9 May 2007 11:35:37 +0200
>
> > After rethinking there is the 3-rd way (as usual):
> >
> > c) vlan should use different lockdep lock subcla
On Thu, Apr 26, 2007 at 12:49:50PM +0200, Jarek Poplawski wrote:
...
> But there is also a second, very similar lockdep report,
> probably also false (lockdep cannot see the difference
> between locks of two different, I hope, vlan devices),
> which needs more work:
> a) vlan shoul
On Thu, Apr 26, 2007 at 02:11:33PM -0700, Andrew Morton wrote:
>
> I have this floating about in my tree. Is it of any interest?
>
>
>
> From: Jarek Poplawski <[EMAIL PROTECTED]>
I know you've more interesting problems, but I'd like to
straighten someth
uot; (&ppp->wlock) differs from
> > &pch->downl lock taken in "-> #0" (before &vlan_netdev_xmit_lock_key) and
> > lockdep should be notified about this.
> >
> > Reported & tested by: "Yuriy N. Shkandybin" <[EMAIL PROTECTED]&
->downl) taken after "-> #2" (&ppp->wlock) differs from
> > &pch->downl lock taken in "-> #0" (before &vlan_netdev_xmit_lock_key) and
> > lockdep should be notified about this.
> >
> > Reported & tested by: "Yuriy N. Shk
On Wed, Apr 25, 2007 at 10:27:59AM +0200, Eric Sesterhenn / Snakebyte wrote:
> * Herbert Xu ([EMAIL PROTECTED]) wrote:
> > Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> > >
> > > My proposal is: maybe Eric could change this in
> > > xfrm6_tunne
On Mon, Apr 23, 2007 at 08:44:16AM +0200, Jarek Poplawski wrote:
> On Fri, Apr 20, 2007 at 04:35:15PM -0700, David Miller wrote:
> > From: Jarek Poplawski <[EMAIL PROTECTED]>
> > Date: Mon, 12 Mar 2007 11:24:03 +0100
> >
> > > > the ipcomp handler is
On Fri, Apr 20, 2007 at 04:35:15PM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Mon, 12 Mar 2007 11:24:03 +0100
>
> > > the ipcomp handler is xfrm6_rcv(), which calls xfrm6_rcv_spi(), which
> > > contrary
> > > to all ot
On Tue, Apr 17, 2007 at 09:37:44AM +0200, Jarek Poplawski wrote:
...
> Yuriy - thanks for testing my patch ...(pause) Not!
>
> It seems this patch is not visible in this version - probably
...
Sorry! It was only something with my eyes.
(Probably too much of Pamela!).
Jarek P.
-
To un
Hi,
I didn't analyse this bug report but probably it
is nearly connected with one of the bugs visible in
a log from this submit:
http://bugzilla.kernel.org/show_bug.cgi?id=8132
On 15-04-2007 02:50, Paul Mackerras wrote:
> David Miller writes:
>
>> Here is Patrick McHardy's patch:
>
> So this d
On Tue, Apr 17, 2007 at 08:26:32AM -0500, Michal Ostrowski wrote:
> The "xmit" function of a PPP channel is a synchronous operation. If the
> transmission fails, we must notify the caller and let them re-submit the
> skb later. The return status of dev_queue_xmit is needed to determine
> the r
On Fri, Apr 06, 2007 at 07:19:25PM +0100, Christian Kujau wrote:
> On Wed, 4 Apr 2007, Christian Kujau wrote:
> >>Maybe it's a real locking problem. Here are some more
> >>suggestions for testing (if you don't find anything better):
> >>- try without SMP, so: 'acpi=off lapic nosmp'
>
> We were abl
On Wed, Apr 11, 2007 at 12:52:28PM +0400, Yuriy N. Shkandybin wrote:
...
> >On Wed, 11 Apr 2007 09:57:33 +0400 "Yuriy N. Shkandybin" <[EMAIL PROTECTED]>
> >wrote:
> >
> >>I've tested 2.6.21-rc6-mm1
> >>Linux vpn1 2.6.21-rc6-mm1 #4 SMP Wed Apr 11 03:34:26 MSD 2007 x86_64
> >>Intel(R) Pentium(R) D
On Wed, Apr 04, 2007 at 02:20:23PM +0100, Christian Kujau wrote:
> On Wed, 4 Apr 2007, Jarek Poplawski wrote:
> >So, it's a lot sooner than before. (BTW, isn't there anything
> >in debug log?)
>
> No, nothing. I've set up remote-syslgging to the other node
On Tue, Apr 03, 2007 at 04:19:46PM +0100, Christian Kujau wrote:
> On Tue, 3 Apr 2007, Jarek Poplawski wrote:
> >Did you try with 8139cp instead of 8139too?
>
> Tried that, 8139cp could not be loaded :(
Sorry for misleading!
> >(Maybe even try some other card to narrow
On 02-04-2007 21:41, Christian Kujau wrote:
>
> Hi there,
>
> we have serious problems with 2 of our servers: both shiny new amd64
> dual core, with both 2GB RAM, 32bit kernel+userland (Debian/testing).
> Both servers have 2 NICs, RTL8139 (eth0, irq10) and RTL8169s
> (eth1, irq11).
Hi,
Did you
On Thu, Mar 29, 2007 at 12:03:26PM +0200, Jarek Poplawski wrote:
...
> rt_cache_flush - it's not for all (I know - we don't like
> multipath - but untill it's here...)[...]
Sorry, I forgot it's already not there...
Jarek P.
-
To unsubscribe from this list: send the li
On Wed, Mar 28, 2007 at 09:34:36PM +0200, Thomas Graf wrote:
> * David Miller <[EMAIL PROTECTED]> 2007-03-28 11:24
> > Another idea Thomas and I tossed around was to have some kind of way
> > for the rule insertion to indicate that the flush should be deferred
> > and I kind of prefer that explicit
On 27-03-2007 14:38, Thomas Graf wrote:
> The results of FIB rules lookups are cached in the routing cache
> except for IPv6 as no such cache exists. So far, it was the
> responsibility of the user to flush the cache after modifying any
> rules. This lead to many false bug reports due to misunderst
talled.
...
lockdep has seen locks "-> #0" - "-> #3" taken in circular
order, but IMHO, lock "-> #3" (&pch->downl) taken after
"-> #2" (&ppp->wlock) differs from &pch->downl lock taken in
"-> #0" (before &v
On Thu, Mar 15, 2007 at 08:43:59AM +0100, Patrick McHardy wrote:
...
> Yes, Robert already sent me a patch to remove the bogus preempt_disable,
It looks like RCU could be endangered now.
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAI
On Thu, Mar 15, 2007 at 10:15:44AM +0100, Jarek Poplawski wrote:
...
> BTW: it seems fib_tree wasn't used too much, so probably,
> before killing fib_hash, fib_tree should be made Kconfig
> default for some time.
Sorry! Let fib_tree stay out of Kconfig and make fib_trie
the def
On Thu, Mar 15, 2007 at 08:43:59AM +0100, Patrick McHardy wrote:
...
> > On 14-03-2007 23:49, Patrick McHardy wrote:
...
> >>BUG: sleeping function called from invalid context at mm/slab.c:3032
> >>in_atomic():1, irqs_disabled():0
...
> Yes, Robert already sent me a patch to remove the bogus preemp
On 14-03-2007 23:49, Patrick McHardy wrote:
...
> I noticed this a couple of times, but didn't manage to look
> into it yet:
>
> BUG: sleeping function called from invalid context at mm/slab.c:3032
> in_atomic():1, irqs_disabled():0
> no locks held by ip/14309.
>
> Call Trace:
> [] debug_show_he
On Mon, Mar 12, 2007 at 10:22:36PM -0800, Andrew Morton wrote:
> > On Mon, 12 Mar 2007 13:53:11 -0700 (PDT) David Miller <[EMAIL PROTECTED]>
> > wrote:
...
> > And there is absolutely no negotiations about this, I've held back on
> > this for nearly 2 years, and nothing has happened, this code is
On Mon, Mar 12, 2007 at 02:36:46PM +0200, Pekka Enberg wrote:
> On 3/12/07, Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> >So, maybe it's less evil to check those NULLs where possible and add
> >some WARN_ONs here and there...
>
> No, it's much better to oops
On 09-03-2007 08:29, David Miller wrote:
> From: Amit Choudhary <[EMAIL PROTECTED]>
> Date: Thu, 8 Mar 2007 23:22:15 -0800
>
>> Description: Check the return value of kmalloc() in function
>> wrandom_set_nhinfo(), in file net/ipv4/multipath_wrandom.c.
>>
>> Signed-off-by: Amit Choudhary <[EMAIL P
On Mon, Mar 12, 2007 at 11:24:03AM +0100, Jarek Poplawski wrote:
...
> I think your diagnose is correct (all "return -1" should be
> changed to "return 0" in xfrm6_input.c).
Sorry! Of course should be:
I think your diagnose is correct (all "return -1"
On 22-02-2007 22:49, Andrew Morton wrote:
>
> Begin forwarded message:
>
> Date: Thu, 22 Feb 2007 07:56:27 -0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [Bugme-new] [Bug 8057] New: slab corruption running ip6sic
>
>
> http://bugzilla.kernel.org/show_bug.cgi?id=8057
>
>
On 09-03-2007 14:40, Thomas Graf wrote:
> * Kok, Auke <[EMAIL PROTECTED]> 2007-02-08 16:09
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 455d589..42b635c 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -1477,6 +1477,49 @@ gso:
>> skb->tc_verd = SET_TC_AT(skb->tc_verd,AT
On Fri, Mar 09, 2007 at 11:40:04AM +0300, Yuriy N. Shkandybin wrote:
...
> .config is at
> http://bugzilla.kernel.org/attachment.cgi?id=10660&action=view
> Also all information i've provied was recieved by serial console and it's
> not hand writing.
>
> I've checked logs and right before lockup t
On Fri, Mar 09, 2007 at 11:40:04AM +0300, Yuriy N. Shkandybin wrote:
...
> I already have
> CONFIG_PROVE_LOCKING=y
> # CONFIG_4KSTACKS is not set
> .config is at
> http://bugzilla.kernel.org/attachment.cgi?id=10660&action=view
> Also all information i've provied was recieved by serial console and i
On 07-03-2007 23:42, David Miller wrote:
> I didn't say to use skb->priority, I said to shrink skb->priority down
> to a u16 and then make another u16 which will store your queue mapping
> value.
Peter is right: this is fully used by schedulers (prio,
CBQ, HTB, HFSC...) and would break users' scri
On Thu, Mar 08, 2007 at 10:02:30PM +1100, Herbert Xu wrote:
> On Thu, Mar 08, 2007 at 10:00:23PM +1100, Herbert Xu wrote:
> >
> > Who's calling ipv6_add_addr from softirq context? That's got to be
> > wrong because ipv6_add_addr requires the RTNL.
>
> Nevermind, I was thinking of ipv6_add_dev.
A
On 06-03-2007 00:13, Andrew Morton wrote:
> On Mon, 5 Mar 2007 14:26:30 -0800
> [EMAIL PROTECTED] wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=8132
>>
>>Summary: pptp server lockup in ppp_asynctty_receive()
>> Kernel Version: 2.6.20
>> Status: NEW
>>
d that dev->lock taken from softirq in ipv6_add_addr
is also taken in sctp_v6_copy_addrlist with softirqs enabled, so
lockup is possible.
Noticed-by: Simon Arlott <[EMAIL PROTECTED]>
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.21-rc2-mm2-/net/sctp/ipv6
On Wed, Mar 07, 2007 at 01:37:44PM +0100, Tore Anderson wrote:
> Document that equal-cost multipath routing with caching does not work
> for forwarded packets.
>
> Signed-Off-By: Tore Anderson <[EMAIL PROTECTED]>
> ---
>
> * Jarek Poplawski
>
> >It is
On 06-03-2007 20:19, David Miller wrote:
> Wei, I have to revert your change, it is incorrect as pointed
> out by other people here on netdev.
>
> BSD sockets basically define the 'backlog' parameter to listen()
> to mean "allow backlog + 1" connections to be queued to the socket.
> This allows a
On 06-03-2007 21:36, Tore Anderson wrote:
>
> Hello list,
>
> I've been trying to figure out how to make equal-cost multipath
> routing work, with no luck. Asked on the LARTC list with no success,
It is probably one of the most often asked questions
on the LARTC, so I'd suggest to look at
On Sun, Feb 18, 2007 at 10:27:19PM -0800, Ben Greear wrote:
> Jarek Poplawski wrote:
> >On Fri, Feb 16, 2007 at 11:04:02AM -0800, Ben Greear wrote:
...
> >>>On Thu, 15 Feb 2007 23:40:32 -0800
> >>>Ben Greear <[EMAIL PROTECTED]> wrote:
> >>>
On Thu, Mar 01, 2007 at 11:27:34AM -0800, Jean Tourrilhes wrote:
> On Thu, Mar 01, 2007 at 08:42:09AM +0100, Jarek Poplawski wrote:
> > On Wed, Feb 28, 2007 at 10:45:41AM -0800, Jean Tourrilhes wrote:
> > > > > +
> > > > > + if ((size <= 0) || (i >
On Thu, Mar 01, 2007 at 01:30:20PM +0200, Ilpo Järvinen wrote:
> On Wed, 28 Feb 2007, Jarek Poplawski wrote:
...
> > Probably something for the next "BTW".
...
> missing. Spotted by Jarek Poplawski.
Thanks! But I really think such a cosmetic suggestion
isn't worth
On Wed, Feb 28, 2007 at 10:45:41AM -0800, Jean Tourrilhes wrote:
> On Wed, Feb 28, 2007 at 10:34:37AM +0100, Jarek Poplawski wrote:
> > On 28-02-2007 02:27, Jean Tourrilhes wrote:
> > > Hi all,
> > ...
> > > Patch for 2.6.20 is attached. The patch was tes
On 27-02-2007 16:50, Ilpo Järvinen wrote:
> New sysctl tcp_frto_response is added to select amongst these
...
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
> @@ -762,15 +763,17 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp,
> }
>
> /* Set slow start threshold and cwnd not falling to slow star
On Wed, Feb 28, 2007 at 10:34:37AM +0100, Jarek Poplawski wrote:
> On 28-02-2007 02:27, Jean Tourrilhes wrote:
...
> > + /* This function is only used for network interface.
> > +* Some hotplug package track interfaces by their name and
> > +* therefore want to
On 28-02-2007 02:27, Jean Tourrilhes wrote:
> Hi all,
...
> Patch for 2.6.20 is attached. The patch was tested on a system
> running the hotplug scripts, and on another system running udev.
>
> Have fun...
>
> Jean
>
> Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
>
On 26-02-2007 23:08, Luca Tettamanti wrote:
> Hello,
> I'm running 2.6.21 (current git, at 9654640d0af). kernel blows up at
> startup, when running setkey. Kernel 2.6.20 runs fine. A couple of words
...
> [ cut here ]
> kernel BUG at /home/kronos/src/linux-2.6.git/net/core/s
On Wed, Feb 21, 2007 at 10:55:55AM -0800, Stephen Hemminger wrote:
> This is what I was suggesting by getting rid of the work queue completely.
...
> --- bridge.orig/net/bridge/br_if.c2007-02-21 10:22:46.0 -0800
> +++ bridge/net/bridge/br_if.c 2007-02-21 10:53:25.0 -0800
> @@ -7
On Wed, Feb 21, 2007 at 09:23:45AM +0100, Jarek Poplawski wrote:
...
> I have known issues with RCU, but dare to disagree here.
> It's done during call_rcu, so anything RCU friendly shouldn't
> see this at the moment at all. It could be needed for those
> with refcounti
On Tue, Feb 20, 2007 at 04:24:34PM -0800, Stephen Hemminger wrote:
> On Wed, 21 Feb 2007 01:19:41 +0300
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
>
> > If del_nbp()->cancel_delayed_work(carrier_check) fails, port_carrier_check()
> > may run later and access an already freed container (struct
> >
On Fri, Feb 16, 2007 at 08:06:25AM -0800, Ben Greear wrote:
...
> Well, I had lockdep and all of the locking debugging I could find
> enabled, but
> it did not catch this problem..I had to use sysctl -t and manually dig
> through the backtraces
> to find the deadlock
>
> It may be that lockd
On 17-02-2007 17:25, Evgeniy Polyakov wrote:
> On Fri, Feb 16, 2007 at 09:34:27PM +0300, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
>> Otherwise we can extend select output mask to include hungup too
>> (getting into account that hungup is actually output event).
>
> This is another possible w
On Fri, Feb 16, 2007 at 09:20:34PM +0100, Francois Romieu wrote:
> Jarek Poplawski <[EMAIL PROTECTED]> :
...
> > > @@ -1603,18 +1605,21 @@ static void rtl8139_thread (struct work_struct
> > > *work)
> > > struct net_device *dev = tp->mii.dev;
>
On Mon, Feb 19, 2007 at 08:11:59AM +0100, Jarek Poplawski wrote:
> On Sun, Feb 18, 2007 at 10:27:19PM -0800, Ben Greear wrote:
..
> > You are also changing the semantics of ASSERT_RTNL (assert *this thread*
> > has rtnl, from the
> > old behaviour: assert *some thread*
On Mon, Feb 19, 2007 at 07:55:48AM +0100, Jarek Poplawski wrote:
...
> So to use this we only need such changes:
>
> ... some_delayed_work_func(...)
> {
> ...
> - rtnl_lock();
> + rtnl_lock_work();
> ...
> - rtnl_unlock(
On Sun, Feb 18, 2007 at 10:27:19PM -0800, Ben Greear wrote:
> Jarek Poplawski wrote:
> >On Fri, Feb 16, 2007 at 11:04:02AM -0800, Ben Greear wrote:
> >
> >>Stephen Hemminger wrote:
> >>
> >>>On Thu, 15 Feb 2007 23:40:32 -0800
> >>>Ben
duled_work;
/* or cancel_rearming_delayed_work(...); etc. */
+ rtnl_unset_flush();
}
(Or there could be added some wrappers like:
rtnl_flush_scheduled_work etc. with these rtnl_set/unset
included.)
PS: destroy_workqueue() is one of dangerous too.
This patch should be applied af
e isn't a way to see if *this* thread is the owner of the RTNL
> currently? I think lockdep knows the owner...maybe could query it somehow,
> or just save the owner in the mutex object when debugging is enabled...
Here is my patch proposal to enable such thing
(and to make
On Fri, Feb 16, 2007 at 10:04:25AM +0100, Jarek Poplawski wrote:
> On Fri, Feb 16, 2007 at 12:23:05AM -0800, Ben Greear wrote:
...
> > I don't see how asserting it in the rtnl_lock would help anything,
> > because at that
> > point we are about to deadlock anyway...
On Fri, Feb 16, 2007 at 12:23:05AM -0800, Ben Greear wrote:
> Jarek Poplawski wrote:
> >On Thu, Feb 15, 2007 at 11:40:32PM -0800, Ben Greear wrote:
> >...
> >
> >>Maybe there should be something like an ASSERT_NOT_RTNL() in the
> >>flush_scheduled_
On Thu, Feb 15, 2007 at 11:40:32PM -0800, Ben Greear wrote:
...
> Maybe there should be something like an ASSERT_NOT_RTNL() in the
> flush_scheduled_work()
> method? If it's performance criticial, #ifdef it out if we're not
> debugging locks?
Yes! I thought about the same (at first). But in my
On 15-02-2007 23:37, Francois Romieu wrote:
> Your usual dont-flush_scheduled_work-with-RTNL-held stuff.
>
> It is a bit different here since the thread runs permanently
> or is only occasionally kicked for recovery depending on the
> hardware revision.
>
> Signed-off-by: Francois Romieu <[EMAIL
On 14-02-2007 22:27, Stephen Hemminger wrote:
> Ben found this but the problem seems pretty widespread.
>
> The following places are subject to deadlock between flush_scheduled_work
> and the RTNL mutex. What can happen is that a work queue routine (like
> bridge port_carrier_check) is waiting for
On Tue, Feb 13, 2007 at 12:35:53PM -0800, David Miller wrote:
...
> I've applied this patch, thanks everyone.
>
> Stephen, do we want this in -stable?
I got this info it went trough -mm too:
...
> From: [EMAIL PROTECTED]
> Subject: - br_if-oops-in-port_carrier_check.patch removed from -mm tree
On Mon, Feb 12, 2007 at 09:47:38AM -0800, Stephen Hemminger wrote:
> On Mon, 12 Feb 2007 11:28:48 +0100
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > Here is my patch proposal for testing.
> > If it doesn't work - forget about it.
> > (Prepared with 2
ascal Terjan <[EMAIL PROTECTED]>
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.20-git6-/net/bridge/br_if.c
linux-2.6.20-git6/net/bridge/br_if.c
--- linux-2.6.20-git6-/net/bridge/br_if.c 2007-02-12 10:20:14.0
+0100
+++ linux-2.6.20-git6/n
On 06-02-2007 22:57, Andrew Morton wrote:
...
> First time slattach is run to set up a SLIP line all is ok.
> If slattach process is then killed and restarted it fails with message:
> SLIP_set_disc(1): File exists
> Problem still occurs in 2.6.20rc6 kernel
>
> dmesg shows:
> object_add failed for
On Fri, Feb 09, 2007 at 09:52:04AM -0800, Stephen Hemminger wrote:
> On Fri, 9 Feb 2007 08:42:11 +0100
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > On 07-02-2007 23:09, Stephen Hemminger wrote:
> > > On Wed, 7 Feb 2007 12:52:16 -0800
> > >
On 07-02-2007 23:09, Stephen Hemminger wrote:
> On Wed, 7 Feb 2007 12:52:16 -0800
> Andrew Morton <[EMAIL PROTECTED]> wrote:
...
>> Feb 7 21:20:18 plop kernel: BUG: unable to handle kernel paging request at
>> virtual address 6b6b6b6b
>> Feb 7 21:20:18 plop kernel: printing eip:
>> Feb 7 21:20:
On Mon, Feb 05, 2007 at 06:14:13PM +0100, Simon Lodal wrote:
...
> Regards
...
It seems decisions makers need more time, so I'd add
2 cents more:
1c: an indentation could be improved (spaces around
operators), like in these places:
>+#define HTB_MAX_CLS (TC_H_MIN(-1)+1)
...
>+ ht
On Mon, Feb 05, 2007 at 06:14:13PM +0100, Simon Lodal wrote:
> On Monday 05 February 2007 11:16, Jarek Poplawski wrote:
> > On 01-02-2007 12:30, Andi Kleen wrote:
> > > Simon Lodal <[EMAIL PROTECTED]> writes:
> > >> Memory is generally not an issue, but CPU is,
401 - 500 of 643 matches
Mail list logo
