James Chapman wrote, On 02/26/2008 01:14 PM:
...
> Luckily, I'm in the lab where my two borrowed servers are today so I
> have access to their consoles. Hopefully I'll be able to find out why
> there are hanging. Btw, they don't hang if I disable irqs around the
> ppp_input() call.
Maybe you've
On Tue, Feb 26, 2008 at 01:03:34PM +, Jarek Poplawski wrote:
> On Tue, Feb 26, 2008 at 12:14:26PM +, James Chapman wrote:
...
> > there are hanging. Btw, they don't hang if I disable irqs around the
> > ppp_input() call.
>
> ...and disabling bh instead isn&#
On Tue, Feb 26, 2008 at 12:14:26PM +, James Chapman wrote:
> Jarek Poplawski wrote:
>> Jarek Poplawski wrote, On 02/25/2008 02:39 PM:
>> ...
>>> Hmm... Wait a minute! But on the other hand David has written about
>>> his cons here, and it looks reasonable: t
On Tue, Feb 26, 2008 at 06:59:08PM +0900, Wei Yongjun wrote:
> Jarek Poplawski wrote:
>
> Maybe ip_error() does not handle the ESRCH error. In this place ESRCH eq
> to ENETUNREACH?
It doesn't handle ESRCH for sure... Current solution seems to expect
it is changed earlier t
On 26-02-2008 07:34, Li Yewang wrote:
> Hi All
>
>There is a bug about icmp netunreach.
>If the kernel does not find a route for a packet,
>it must send a icmp netunreach packet to the source host,
>and discard the packet. But the kernel does not send
>a icmp netunreach
Jarek Poplawski wrote, On 02/25/2008 02:39 PM:
...
> Hmm... Wait a minute! But on the other hand David has written about
> his cons here, and it looks reasonable: this place would be fixed,
> but some others can start reports like this. Maybe, it's better to
> analyze yet if it&#x
On Mon, Feb 25, 2008 at 01:39:48PM +, Jarek Poplawski wrote:
...
> Maybe, it's better to
> analyze yet if it's really so hard to eliminate taking this lock
> on the xmit path?
BTW, I'm not sure if it helps, but this matters only for the sockets
which could be used
On Mon, Feb 25, 2008 at 01:05:08PM +, Jarek Poplawski wrote:
...
> On Mon, Feb 25, 2008 at 12:19:50PM +, James Chapman wrote:
> > Is this an acceptable solution? If so, I'll prepare and send official
> > patches.
>
> IMHO this should be acceptable because
On Mon, Feb 25, 2008 at 12:19:50PM +, James Chapman wrote:
> Jarek Poplawski wrote:
>> Jarek Poplawski wrote, On 02/21/2008 01:08 PM:
>> ...
>>
>>> Another, probably simpler way would be to move almost all pppol2tp_xmit
>> ...
>>
>> Actually, th
On Mon, Feb 25, 2008 at 12:48:38PM +0200, Denys Fedoryshchenko wrote:
> What does it mean early?
> I have custom boot scripts, it is also custom system based on busybox. There
> is a chance that i forgot to bring ifb0 up, but thats it.
> I think such warning must not appear on any actions in users
On 24-02-2008 23:20, Denys Fedoryshchenko wrote:
> 2.6.24.2 with applied patches for printk,softlockup, and patch for htb (as i
> understand, they are in 2.6.25 git and it is fixes).
>
> I will send also to private mails QoS rules i am using.
>
> [ 118.840072] ==
On Sun, Feb 24, 2008 at 04:10:29AM +0100, Jann Traschewski wrote:
> Hello,
Hi!
> I got a "spinlock lockup" using the latest Kernel 2.6.24.2 with recent
> patches from Jarek Poplawski applied.
...
> ppp_deflate nf_nat zlib_deflateBUG: unable to handle kernel NULL
ed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
[not tested]
---
net/core/sock.c | 79 +++
1 files changed, 56 insertions(+), 23 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 433715f..18c33d2 100644
--- a/net/core/s
Jarek Poplawski wrote, On 02/21/2008 01:08 PM:
...
> Another, probably simpler way would be to move almost all pppol2tp_xmit
...
Actually, the simplest off all seems to be now this old idea to maybe make
sk_dst_lock globally softirq immune. At least I think it's worth of testing,
to c
On Thu, Feb 21, 2008 at 09:53:56AM +, James Chapman wrote:
> Jarek Poplawski wrote:
...
> The _bh locking fixes in pppol2tp combined with your ppp_generic change
> solved that problem. So I then added data traffic into the mix (since
> this will happen in a real network) an
On Wed, Feb 20, 2008 at 10:37:57PM +, James Chapman wrote:
> Jarek Poplawski wrote:
>
>>>> (testing patch #1)
>>
>> But I hope you tested with the fixed (take 2) version of this patch...
>
> Yes I did. :)
>
> But I just got another lockdep error (att
On Wed, Feb 20, 2008 at 04:02:52PM +, James Chapman wrote:
...
> I tried your ppp_generic patch with only the hlist_lock bh patch in
> pppol2tp and it seems to fix the ppp create/delete issue. However, when
> I added much more traffic into the test (flood pings over ppp interfaces
> while
On Wed, Feb 20, 2008 at 02:54:27PM +0300, Badalian Vyacheslav wrote:
> Khrm i try to say that i have language barrier and some time may
> wrong compose clauses. Example below =)
No, only a bit joking...
> "I'll try fix my English next time!"
Don't worry Vyacheslav: I think your message was
On Wed, Feb 20, 2008 at 12:25:32PM +0300, Badalian Vyacheslav wrote:
...
> Please not think that it disrespect for you. Its simple language barrier =(
OK! Don't disrespect for me - I'll try fix my English next time!)
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" i
On 18-02-2008 10:18, Badalian Vyacheslav wrote:
> Hello all.
Hi,
> Interesting think:
>
> Have PC that do NAT. Bandwidth about 600 mbs.
>
> Have 4 CPU (2xCoRe 2 DUO "HT OFF" 3.2 HZ).
>
> irqbalance in kernel is off.
>
> nat2 ~ # cat /proc/irq/217/smp_affinity
> 0001
> nat2 ~ # cat /proc/
On 19-02-2008 23:58, Adrian Bunk wrote:
...
> --- a/net/mac80211/ieee80211_sta.c
> +++ b/net/mac80211/ieee80211_sta.c
> @@ -1116,9 +1116,10 @@ static void ieee80211_sta_process_addba_request(struct
> net_device *dev,
...
> + printk(KERN_ERR "can not allocate reordering buffer "
On Wed, Feb 20, 2008 at 12:06:40AM +0100, Jarek Poplawski wrote:
...
> (testing patch #1)
SORRY!!! > take 2 (unlocking fixed)
---
drivers/net/ppp_generic.c | 39 +--
1 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/drive
On Mon, Feb 18, 2008 at 10:09:24PM +, James Chapman wrote:
...
> Unfortunately the ISP's syslog stops. But I've been able to borrow
> two Quad Xeon boxes and have reproduced the problem.
>
> Here's a new version of the patch. The patch avoids disabling irqs
> and fixes the sk_dst_get() usage th
On Tue, Feb 19, 2008 at 10:30:47AM +, Jarek Poplawski wrote:
...
> IMHO, just like I wrote earlier, the main problem is in ppp_generic(),
...or maybe ppp_generic.c? Whatever...
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mess
On Tue, Feb 19, 2008 at 09:03:12AM +, James Chapman wrote:
> David Miller wrote:
>> From: James Chapman <[EMAIL PROTECTED]>
>> Date: Mon, 18 Feb 2008 22:09:24 +
>>
>>> Here's a new version of the patch. The patch avoids disabling irqs
>>> and fixes the sk_dst_get() usage that DaveM mentione
Jarek Poplawski wrote, On 02/18/2008 11:10 PM:
> A few usage description fixes of tc filters for some minimal
> consistency (FILTER_KIND because of QDISC_KIND).
>
>
> Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
Don't apply: I've sent 2nd version of this
CLASSID := X:Y:Z ==> X:Y in f_basic is changed here and no change for
f_u32 (it has both CLASSID and FILTERID mentioned).
-> (take 2)
A few usage description fixes of tc filters for some minimal
consistency (FILTER_KIND because of QDISC_KIND).
Signed-off-by: Jarek Pop
On Mon, Feb 18, 2008 at 10:09:24PM +, James Chapman wrote:
> Jarek Poplawski wrote:
>> Hi,
>>
>> It seems, this nice report is still uncomplete: could you check if
>> there could have been something more yet?
>
> Unfortunately the ISP's syslog stops. B
A few usage description fixes of tc filters for some minimal
consistency (FILTER_KIND because of QDISC_KIND).
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
tc/f_basic.c |4 ++--
tc/f_rsvp.c|2 +-
tc/f_u32.c |2 +-
tc/tc_filter.c |6 +++---
4 files chan
On Sun, Feb 17, 2008 at 02:03:33AM +0200, Denys Fedoryshchenko wrote:
> Server is fully redundant now, so i apply patches (but i apply both, probably
> it will make system more reliable somehow) and i enable required debug
> options in kernel. So i will try to catch this bug few more times, proba
On Sat, Feb 16, 2008 at 12:25:31PM +0200, Denys Fedoryshchenko wrote:
> Thanks, i will try it.
> You think lockdep can be buggy?
Just like every code... But the main reason is it has quite meaningful
overhead, so could be right "in production" only after lockups happen.
But if it doesn't report an
Denys Fedoryshchenko wrote, On 02/13/2008 09:13 AM:
> It is very difficult to reproduce, happened after running about 1month. No
> changes done in classes at time of crash.
>
> Kernel 2.6.24 vanilla
Hi,
I could be wrong, but IMHO this looks like stack was overridden here,
so my proposal is to
Jarek Poplawski wrote, On 02/15/2008 10:03 PM:
...
> ...On the other hand this:
>
>> Feb 15 15:50:17 217.151.X.X [1521315.068984] BUG: spinlock lockup on CPU#1,
>> ksoftirqd/1/7, f0551180
>
> seems to point just at spinlock lockup, so it's more about the full rep
Jarek Poplawski wrote, On 02/15/2008 09:21 PM:
> Denys Fedoryshchenko wrote, On 02/15/2008 08:42 PM:
> ...
>
>> I have similar crashes on completely different hardware with same job (QOS),
>> so i think it is actually some nasty bug in networking.
>
> Maybe yo
Denys Fedoryshchenko wrote, On 02/15/2008 08:42 PM:
...
> I have similar crashes on completely different hardware with same job (QOS),
> so i think it is actually some nasty bug in networking.
Maybe you could try with some other debugging options? E.g. since lockdep
doesn't help - turn this off.
Hi,
It seems, this nice report is still uncomplete: could you check if
there could have been something more yet?
Thanks,
Jarek P.
On Tue, Feb 12, 2008 at 10:58:21AM +, James Chapman wrote:
...
> Here is a trace from when we had _bh locks.
>
> Feb 5 16:26:32 ===
= 0 can happen in ax25_output(); this wasn't confirmed
during testing but let's leave this debugging check for some time.
Reported-and-tested-by: Jann Traschewski <[EMAIL PROTECTED]>
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp 2.6.24-mm1-/net/ax25/ax25_o
n't complete,
so the real reason of the later bug could be different, but
IMHO this locking break in ax_bump is unsafe and unnecessary.
Reported-and-tested-by: Jann Traschewski <[EMAIL PROTECTED]>
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
drivers/net/hamradio/mki
On 12-02-2008 22:51, PJ Waskiewicz wrote:
> This updates the help output to specify that CLASSID should be hexidecimal.
...
> + fprintf(stderr, "\nNOTE: CLASSID is parsed as hexidecimal input.\n");
s/hexidecimal/hexadecimal/g (?)
Regards,
Jarek P.
--
To unsubscribe from this list: send the li
On 13-02-2008 09:13, Denys Fedoryshchenko wrote:
> It is very difficult to reproduce, happened after running about 1month. No
> changes done in classes at time of crash.
>
> Kernel 2.6.24 vanilla
>
> I will try to attach also .config
>
Hi Denys,
This report looks very interesting. I don't kno
On 13-02-2008 01:50, Stephen Hemminger wrote:
...
> --- a/include/linux/rcupdate.h2008-02-12 14:46:49.0 -0800
> +++ b/include/linux/rcupdate.h2008-02-12 14:56:17.0 -0800
> @@ -178,7 +178,7 @@ struct rcu_head {
>
> #define rcu_assign_pointer(p, v)
On Tue, Feb 12, 2008 at 10:00:03PM -0800, David Miller wrote:
> From: James Chapman <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 10:58:21 +
>
> > Here is a trace from when we had _bh locks.
>
> The problem is that the pppol2tp code calls sk_dst_get() in software
> interrupt context and that i
On Tue, Feb 12, 2008 at 08:32:18PM +0100, Jarek Poplawski wrote:
...
> It seems the above version of this macro uses the barrier for 0, but
> if I miss something, or for these other: documenting reasons,
...or __builtin_constants could be used for indexing (?!),
> then of
> course y
On Tue, Feb 12, 2008 at 08:07:29AM -0800, Paul E. McKenney wrote:
...
> "All programmers are blind, especially me."
Hmm... I got it my way: you - superheroes - sometimes seem to be just
like us - common people... (Probably early in the morning, before
dressing your funny costumes?)
> You are rig
On Tue, Feb 12, 2008 at 10:58:21AM +, James Chapman wrote:
...
> Here is a trace from when we had _bh locks.
Very nice...
...But since it's quite long, and if you don't know all these paths
this could take some time, maybe one question: so if lockdep got these
locks right (sometimes it can be
On Mon, Feb 11, 2008 at 11:42:12PM +, James Chapman wrote:
> Jarek Poplawski wrote:
>> On Mon, Feb 11, 2008 at 11:49:24PM +0100, Jarek Poplawski wrote:
>>> On Mon, Feb 11, 2008 at 10:19:35PM +, James Chapman wrote:
>>> ...
>>>> Below is example output
On Tue, Feb 12, 2008 at 09:43:26AM +0100, Jann Traschewski wrote:
> Applied on 2.6.24.2 and up without any problems/warnings since 12 hours.
> Thanks,
> Jann
Thanks Jann, too!
BTW, I hope maybe until tomorrow I'll figure out something about those
earlier two AX25 testing patches.
Regards,
Jarek
On 12-02-2008 02:16, David Miller wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Mon, 11 Feb 2008 16:59:54 -0800
>
> linux-kernel added to CC:, any change to generic kernel infrastructure
> should be posted there
>
>> Eliminate warnings when rcu_assign_pointer is used with unsigned
On Mon, Feb 11, 2008 at 11:41:18PM +, James Chapman wrote:
> Jarek Poplawski wrote:
>> On Mon, Feb 11, 2008 at 10:19:35PM +, James Chapman wrote:
>> ...
>>> Below is example output from lockdep. The oops is reproducible when
>>> creating/deleting lots of
On Mon, Feb 11, 2008 at 11:49:24PM +0100, Jarek Poplawski wrote:
> On Mon, Feb 11, 2008 at 10:19:35PM +, James Chapman wrote:
> ...
> > Below is example output from lockdep. The oops is reproducible when
> > creating/deleting lots of sessions while passing data.
On Mon, Feb 11, 2008 at 10:19:35PM +, James Chapman wrote:
...
> Below is example output from lockdep. The oops is reproducible when
> creating/deleting lots of sessions while passing data. The lock is being
> acquired for read and write in softirq contexts.
>
> Is there a better way to fix
James Chapman wrote, On 02/11/2008 10:22 AM:
> Fix locking issues in the pppol2tp driver which can cause a kernel
> crash on SMP boxes when hundreds of L2TP sessions are created/deleted
> simultaneously (ISP environment). The driver was violating read_lock()
> and write_lock() scheduling rules so
is safe, all write_locks in ax25_route.c are changed to
_bh versions.
Reported-by: Jann Traschewski <[EMAIL PROTECTED]>,
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp 2.6.24-mm1-/net/ax25/ax25_route.c 2.6.24-mm1+/net/ax25/ax25_route.c
--- 2.6.24-mm1-/net/ax25/ax25_route.
On 11-02-2008 08:00, Patrick McHardy wrote:
...
> Indeed, I'm currently ill and not really up for much working,
> but this will hopefully get better soon.
Wish you well, Patrick!
I hope it's about some WARN_ON not BUG_ON?
Anyway, drop these last patches and get back to stable!
Regards,
Jarek P.
ilar
reading without this lock too).
So, this patch removes sock lock to avoid deadlock possibility; there
is also used sock_i_ino() function, which reads sk_socket under proper
read lock. Additionally printf format of this i_ino is changed to %lu.
Reported-by: Bernard Pidoux F6BVP <[EMAIL PROTE
e.g.
ax25_send_to_raw() does similar reading without this lock too). So,
this patch removes this lock to avoid deadlock possibility.
Reported-by: Bernard Pidoux F6BVP <[EMAIL PROTECTED]>
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
net/ax25/af_ax25.c |2 --
1 files chang
On Sat, Feb 09, 2008 at 07:44:50PM +0100, Bernard Pidoux F6BVP wrote:
> Hi,
>
> With AX25 patches applied I still get this possible circular locking
> message.
Hi Bernard,
Could you confirm which exactly patches did you try? Is this vanilla
2.6.24 plus these two: ax25_timer and ax25_ds_timer or
htb_requeue() enqueues skbs for which htb_classify() returns NULL.
This is wrong because such skbs could be handled by NET_CLS_ACT code,
and the decision could be different than earlier in htb_enqueue().
So htb_requeue() is changed to work and look more like htb_enqueue().
Signed-off-by: Jarek
On Thu, Feb 07, 2008 at 08:35:11PM +0100, Jarek Poplawski wrote:
> Here I resend another OOPS I got from Jann:
>
> On Thu, Feb 07, 2008 at 05:42:42PM +0100, Jann Traschewski wrote:
> ...
> > BUG: unable to handle kernel NULL pointer dereference at virtual address
> > 0
Here I resend another OOPS I got from Jann:
On Thu, Feb 07, 2008 at 05:42:42PM +0100, Jann Traschewski wrote:
...
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 0065
> printing eip: c02266c7 *pde =
> Oops: [#1] SMP
> Modules linked in: netconsole ppp
> -- Forwarded message --
> From: Jann Traschewski <[EMAIL PROTECTED]>
> Date: Thu, 7 Feb 2008 06:27:38 +0100
> Subject: FW: smp kernel oops ax25 2008-02-07
> To: Jarek Poplawski <[EMAIL PROTECTED]>
...
> BUG: unable to handle kernel NULL pointer
On Wed, Feb 06, 2008 at 07:45:29AM +, Jarek Poplawski wrote:
...
> From: Jann Traschewski <[EMAIL PROTECTED]>
> Subject: SMP with AX.25
(testing patch #2)
According to some OOPSes reported by Jann it seems ax25_kick
tries to clone NULL skbs sometimes. Probably there is needed
On Wed, Feb 06, 2008 at 07:45:29AM +, Jarek Poplawski wrote:
...
> From: Jann Traschewski <[EMAIL PROTECTED]>
> Subject: SMP with AX.25
> To: [EMAIL PROTECTED]
According to one of OOPSes reported by Jann softirq can break
while skb is prepared for netif_rx. The report isn
On Wed, Feb 06, 2008 at 08:15:09AM +, Jarek Poplawski wrote:
> On Wed, Feb 06, 2008 at 07:45:29AM +0000, Jarek Poplawski wrote:
> ...
> > From: Jann Traschewski <[EMAIL PROTECTED]>
> > Subject: SMP with AX.25
...
[AX25] ax25_ds_timer: use mod_timer instead of add_t
On Wed, Feb 06, 2008 at 07:45:29AM +, Jarek Poplawski wrote:
...
> From: Jann Traschewski <[EMAIL PROTECTED]>
> Subject: SMP with AX.25
[AX25] ax25_timer: use mod_timer instead of add_timer
According to one of Jann's OOPS reports it looks like
BUG_ON(timer_pending(timer)
This patch is wrong - don't apply, please!
Sorry,
Jarek P.
On 03-02-2008 15:52, Jarek Poplawski wrote:
> [NET_SCHED] sch_tree_lock in cbq_put, hfsc_put_class and htb_put
>
> Qdisc_class_ops ->put() "methods" call xxx_destroy_class() functions
> without sch_tree_lo
f HTB. (Since errors caused by such a bug could be very hard to
reproduce the effectiveness of this patch wasn't confirmed by tests,
but IMHO the need of this lock is quite obvious here.)
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
net/sched/sch_cbq.c | 14
Corey Hickey wrote, On 02/02/2008 11:23 AM:
...
> I'd rather you were using my recent patches to SFQ instead of ESFQ. I
> was able to crash a 2.6.24 user-mode Linux with ESFQ as well; I don't
> know if that's what you encountered, but the SFQ patches should be
> better anyway.
>
> http://fatooh.
On Sat, Feb 02, 2008 at 12:56:08PM +0200, Julian Anastasov wrote:
>
> Hello,
Hi!
> On Tue, 29 Jan 2008, Jarek Poplawski wrote:
>
> > ...On the other hand, I wonder how bad would be switching these two
> > to avoid this error? After all "replace" wit
YOSHIFUJI Hideaki / 吉藤英明 wrote, On 01/31/2008 08:57 PM:
> Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> ---
> include/linux/if_addrlabel.h | 32 +
> ip/Makefile |2 +-
> ip/ip.c |5 +-
> ip/ip_common.h |4 +
> ip/ipadd
Denys Fedoryshchenko wrote, On 02/01/2008 02:25 PM:
> Hi
>
> Probably bug related to ESFQ, now i will unload module and will test more.
> But probably not related, so if not difficult, please take a look.
Hi,
The main break seems to take place in HTB. Do you use HTB on IFB, BTW?
If not, maybe
jamal wrote, On 02/01/2008 01:06 PM:
> On Fri, 2008-01-02 at 10:56 +0100, Patrick McHardy wrote:
>
>> We don't want to disable TSO for cases where it makes sense, but
>> who is using TBF on 10GbE? The point is that most users of qdiscs
>> which are incapable of dealing with TSO without hacks or s
On Fri, Feb 01, 2008 at 01:28:15AM -0800, Waskiewicz Jr, Peter P wrote:
...
> The TCP layer will generate TSO packets based on the kernel socket
> features associated with the flow. So if you have two devices, one
> supporting TSO, the other not, then the flows associated with the
> non-TSO device
On 01-02-2008 00:04, Jarek Poplawski wrote:
...
> ...On the other hand, with this DSL argument from the sub-thread you
> could be quite right: if this "everyone" wants to use one NIC for
> both high speed local network and such a DSL, then learning ethtool
> could be not eno
Jarek Poplawski wrote, On 01/31/2008 09:33 PM:
> Andi Kleen wrote, On 01/31/2008 08:34 PM
...
>> Basically you're suggesting that nearly everyone using tc should learn about
>> another obscure command
...On the other hand, with this DSL argument from the sub-thread you
Andi Kleen wrote, On 01/31/2008 08:34 PM:
>> TSO by nature is bursty. But disabling TSO without the option of having
>> it on or off to me seems to aggressive. If someone is using a qdisc
>> that TSO is interfering with the effectiveness of the traffic shaping,
>> then they should turn off TSO v
On Tue, Jan 29, 2008 at 10:10:30AM +0100, Jarek Poplawski wrote:
> On Tue, Jan 29, 2008 at 09:49:15AM +0100, Jarek Poplawski wrote:
> > On Tue, Jan 29, 2008 at 02:30:47AM +0200, Julian Anastasov wrote:
> ...
> > > fa_match is some existing alias that matches all new
On Tue, Jan 29, 2008 at 09:49:15AM +0100, Jarek Poplawski wrote:
> On Tue, Jan 29, 2008 at 02:30:47AM +0200, Julian Anastasov wrote:
...
> > fa_match is some existing alias that matches all new parameters.
> > As NLM_F_REPLACE changes the first alternative route for
>
On Tue, Jan 29, 2008 at 02:30:47AM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Mon, 28 Jan 2008, Jarek Poplawski wrote:
>
> > BTW, the way "add" works wasn't questioned now, but it seems could be,
> > or man ip should call it e.g. "ip r
On Mon, Jan 28, 2008 at 09:33:02AM +0100, Jarek Poplawski wrote:
...
> [...] Are these aliases in the node sorted by
> fib_priority too? [...]
OK, I see they are!
Sorry for bothering,
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
On Mon, Jan 28, 2008 at 09:33:02AM +0100, Jarek Poplawski wrote:
...
> from fib_node_alias() with right tos but greater fib_priority, but
"from fib_find_alias()" of course...
arek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
On 28-01-2008 00:20, Jarek Poplawski wrote:
> Hi, I have a few questions below:
>
> Julian Anastasov wrote, On 01/26/2008 01:41 PM:
...
>> --- linux-2.6.24/net/ipv4/fib_hash.c_orig2008-01-25 10:45:06.0
>> +0200
>> +++ linux-2.6.24/net/ipv4/fib_hash.c 20
Hi, I have a few questions below:
Julian Anastasov wrote, On 01/26/2008 01:41 PM:
> fib_info can be shared by many route prefixes but we don't
> want duplicate alternative routes for a prefix+tos+priority. Last
> change was not correct to check fib_treeref because it accounts usage
> from
On Sun, Jan 27, 2008 at 11:49:06AM +0200, Julian Anastasov wrote:
...
> No, simply the last change in 2.6.24 is wrong to assume
> duplication is evident in fib_info reference counter. And such check
> is only on ip route replace/change. I'm appending brief FIB information
> for your referenc
On Sun, Jan 27, 2008 at 02:11:26AM +0100, Jarek Poplawski wrote:
...
> But comment#3 is "ambiguous"... It looks like you don't want to show
> us too much... So, apparently you change the route, but it seems this
> route exists; you have this:
> 10.0.0.0/8 dev eth0
On Sat, Jan 26, 2008 at 04:19:34PM +0100, Jarek Poplawski wrote:
> On Sat, Jan 26, 2008 at 03:27:00PM +0100, Andreas Schwab wrote:
> > Jarek Poplawski <[EMAIL PROTECTED]> writes:
> >
> > > And, after re-reading this bugzilla report, I'm pretty sure the thing
On Sat, Jan 26, 2008 at 03:27:00PM +0100, Andreas Schwab wrote:
> Jarek Poplawski <[EMAIL PROTECTED]> writes:
>
> > And, after re-reading this bugzilla report, I'm pretty sure the thing
> > should be done with 'ip route change' (but I didn't check if 2.
On Sat, Jan 26, 2008 at 03:10:10PM +0100, Jarek Poplawski wrote:
...
> [...] so old thing is always supposed to be
> destroyed (of course it's a matter of implementation or conditions in
> which moment this destruction takes place).
>
> So, 'replace with itself' is s
On Sat, Jan 26, 2008 at 12:40:36PM +0100, Jarek Poplawski wrote:
> On Sat, Jan 26, 2008 at 02:16:01PM +0900, Joonwoo Park wrote:
> > 2008/1/26, Andrew Morton <[EMAIL PROTECTED]>:
> > >
> > > But whatever. It used to work. People's scripts will break.
&
On Fri, Jan 25, 2008 at 07:20:26PM -0800, Andrew Morton wrote:
...
> That's not a very good analogy - the source is a kernel object. A better
> example would be:
>
> linux-2.6.24-rc8:
>
> echo foo > /tmp/1
> echo bar > /tmp/2
> echo foo > /tmp/1
>
> linux-2.6.24:
>
> echo foo > /tmp/1
> echo b
On Sat, Jan 26, 2008 at 02:16:01PM +0900, Joonwoo Park wrote:
> 2008/1/26, Andrew Morton <[EMAIL PROTECTED]>:
> >
> > But whatever. It used to work. People's scripts will break. Regression.
> >
>
> Also I thought that 'replace with itself' should be error as like Jarek.
> But it used to work a
Andrew Morton wrote, On 01/25/2008 11:26 PM:
>> On Fri, 25 Jan 2008 13:23:49 -0800 (PST) [EMAIL PROTECTED] wrote:
>> http://bugzilla.kernel.org/show_bug.cgi?id=9816
...
> I'd agree with Andrea: replacing a route with itself a) used to work and b)
> should still work (surely)?
...on the other ha
it isn't used after all.
Thanks to David Miller for pointing errors in first versions of this patch
and for suggesting proper solution.
Reported-by: Badalian Vyacheslav <[EMAIL PROTECTED]>
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
Documentation/netwo
On Fri, Jan 25, 2008 at 08:13:15AM -0800, Stephen Hemminger wrote:
...
> 2. RCU is unnecessary here because of use of RTNL. I am going to defer
>on this till after #1. That patch is much less important.
Thanks! (I've started to suspect another advanced RCU trick already...)
Jarek P.
--
To un
On 24-01-2008 22:51, Stephen Hemminger wrote:
> Normally during a dump the key of the last dumped entry is used for
> continuation, but since lock is dropped it might be lost. In that case
> fallback to the old counter based N^2 behaviour. This means the dump will
> end up
> skipping some routes
On Tue, Jan 22, 2008 at 08:54:28AM -0500, jamal wrote:
> On Tue, 2008-22-01 at 13:29 +0100, Jarek Poplawski wrote:
> > On Tue, Jan 22, 2008 at 06:42:07AM -0500, jamal wrote:
> > ...
> > > Jarek,
> > >
> > > That looks different from the suggestion from Da
On Tue, Jan 22, 2008 at 06:42:07AM -0500, jamal wrote:
...
> Jarek,
>
> That looks different from the suggestion from Dave.
Hmm..., I'm not sure you mean my or your suggestion here, but you
are right anyway...
> May i throw in another bone? Theoretically i can see why it would be a
> really bad
On Tue, Jan 22, 2008 at 08:21:52AM +0100, Jarek Poplawski wrote:
...
Part 2 of mini RFC:
HTB changes to use new, faster gen_estimator functions._
This is done against 2.6.24-rc8-mm1.
Thanks,
Jarek P.
---
diff -Nurp 2.6.24-rc8-mm1-/net/sched/sch_htb.c
2.6.24-rc8-mm1+/net/sched/sch_htb.c
On 22-01-2008 01:29, David Miller wrote:
...
> Fix this right, make a structure like:
>
> struct kernel_gnet_stats_rate_est {
> struct gnet_stats_rate_est est;
> void*gen_estimator;
> }
>
> And update all the code as needed.
Thanks! I'll try this...
On Mon, Jan 21, 2008 at 11:31:37PM +0100, Jarek Poplawski wrote:
>
> So, let's try something easy first: #ifdef __KERNEL__. (I know there
...
SORRY!!! Of course this is still wrong, I withdraw this patch.
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe net
1 - 100 of 643 matches
Mail list logo
