On 01-02-2007 12:30, Andi Kleen wrote:
> Simon Lodal <[EMAIL PROTECTED]> writes:
>> Memory is generally not an issue, but CPU is, and you can not beat the CPU
>> efficiency of plain array lookup (always faster, and constant time).
Probably for some old (or embedded) lean boxes used for
small netw
On Fri, Feb 02, 2007 at 02:43:11PM +0100, Jarek Poplawski wrote:
> On 02-02-2007 12:53, Fagyal Csongor wrote:
> > Thomas Glanzmann wrote:
...
> Is this with this yesterday sky2-tx-recover.patch applied?
I mean hung-ups - not ethtool.
Regards,
Jarek P.
-
To unsubscribe from this li
On 02-02-2007 12:53, Fagyal Csongor wrote:
> Thomas Glanzmann wrote:
...
>>> Next time sky2 hangs on me I'll try to reset the PHY and see if that
>>> helps. I can usually trigger the hang by doing a couple of ifconfig
>>> up/down on the interface, though I'm not getting any error message
>>> from t
(Take 3)
This patch adds a dump_stats callback to enable
printing of basic statistics of prio classes.
(With help of Patrick McHardy).
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.20-rc6-/net/sched/sch_prio.c
linux-2.6.20-rc6/net/sched/sch_prio.c
---
On Wed, Jan 31, 2007 at 04:06:05PM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> >>From sch_api.c:
> >
> >
> >> if (cl_ops->dump && cl_ops->dump(q, cl, skb, tcm) < 0)
> >> goto rtattr_failure;
>
On Wed, Jan 31, 2007 at 03:37:25PM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> > +static int prio_dump_class_stats(struct Qdisc *sch, unsigned long cl,
> > +struct gnet_dump *d)
> > +{
> > + struct prio_sched_data *q = qdis
(Take 2)
This patch adds a dump_stats callback to enable
printing of basic statistics of prio classes.
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.20-rc6-/net/sched/sch_prio.c
linux-2.6.20-rc6/net/sched/sch_prio.c
--- linux-2.6.20-rc6-/net/sched/sch_
On Wed, Jan 31, 2007 at 02:47:55PM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> > This patch adds a dump_stats callback to enable
> > printing of basic statistics of prio classes.
>
> > diff -Nurp linux-2.6.20-rc6-/net/sched/sch_prio.c
> > linux-2
On 30-01-2007 16:04, Alexey Dobriyan wrote:
> On Tue, Jan 30, 2007 at 03:34:18AM -0800, David Stevens wrote:
>> I think you're correct-- looks like it needs:
>>
>> if (!skb)
>> return NULL;
>>
>> just before the skb_put(), since an allocation (and failure)
>> could o
Hello,
This patch adds a dump_stats callback to enable
printing of basic statistics of prio classes.
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.20-rc6-/net/sched/sch_prio.c
linux-2.6.20-rc6/net/sched/sch_prio.c
--- linux-2.6.20-rc6-/net/sched/sch_
On Mon, Jan 29, 2007 at 09:26:16AM +0100, Jarek Poplawski wrote:
...
> So this patch is changing it to ipv6 way. It seems to
> be quite brave. I think there was some reason to do
> this "old way" and I hope consequences were analyzed.
...
But since Alexey Kuznetsov accepted th
On Fri, Jan 26, 2007 at 09:45:18PM +1100, Herbert Xu wrote:
> On Fri, Jan 26, 2007 at 11:18:38AM +0100, Jarek Poplawski wrote:
> >
> > I don't mean it's necessary. I mean now skb is freed
> > unconditionally and after this patch, if there is some
> > error
On Fri, Jan 26, 2007 at 02:18:08PM +0100, Jarek Poplawski wrote:
...
> I've only now read the original thread of this problem
> and this long note about security. I need more time to
> understand this, but now I'm not sure Masayuki's server
> isn't doing something
On Fri, Jan 26, 2007 at 12:02:35PM +0100, Jarek Poplawski wrote:
> On Fri, Jan 26, 2007 at 09:45:18PM +1100, Herbert Xu wrote:
> > On Fri, Jan 26, 2007 at 11:18:38AM +0100, Jarek Poplawski wrote:
> > >
> > > I don't mean it's necessary. I mean now skb is freed
On Fri, Jan 26, 2007 at 09:45:18PM +1100, Herbert Xu wrote:
> On Fri, Jan 26, 2007 at 11:18:38AM +0100, Jarek Poplawski wrote:
> >
> > I don't mean it's necessary. I mean now skb is freed
> > unconditionally and after this patch, if there is some
> > error
On Fri, Jan 26, 2007 at 08:52:51PM +1100, Herbert Xu wrote:
> On Fri, Jan 26, 2007 at 10:49:50AM +0100, Jarek Poplawski wrote:
> >
> > How do we know about those improper deals?
> > I understand there should be no other users here
> > if it's __kfree_skb
On Fri, Jan 26, 2007 at 08:16:06PM +1100, Herbert Xu wrote:
> On Fri, Jan 26, 2007 at 09:28:38AM +0100, Jarek Poplawski wrote:
> >
> > So maybe for some time there should be added skb->users
> > test with a warning to reveal this?
>
> Or just replace __kfree
On 26-01-2007 04:37, Masayuki Nakagawa wrote:
> This patch simply replaces __kfree_skb() in exit path with kfree_skb().
> In tcp_rcv_state_process(), generally skbs should be destroyed only when
> the ref count is zero.
> That is the way things are supposed to be done in the kernel.
>
> This chang
epted,
just a little.
Regards,
Jarek P.
---
[PATCH][NET_SCHED] sch_htb: htb_class optimization
htb_class_leaf and htb_class_inner are separated from
main htb_class structure to use memory more effectively.
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.20-rc
s right only if you know the function
mv643xx_eth_free_tx_descs is called mostly while
mp->tx_desc_count == 0 or 1.
> - Patch follows -
>
> From: Dale Farnsworth <[EMAIL PROTECTED]>
>
> mv643xx_eth: Fix race condition in mv643xx_eth_free_tx_descs
>
> The bug was found and isolated
On Sun, Jan 21, 2007 at 02:02:15PM +0100, Thibaut VARENE wrote:
> On 1/21/07, Thibaut VARENE <[EMAIL PROTECTED]> wrote:
...
> >Hmm, I think this is guaranteed not to work. In between those lines
> >the lock is released, while data in the mp structure is still being
> >accessed. It seems that this b
On Mon, Jan 22, 2007 at 06:45:57PM +1100, Herbert Xu wrote:
> On Mon, Jan 22, 2007 at 07:52:14AM +0100, Jarek Poplawski wrote:
> >
> > I was so impressed by the amount of work done by Michael
> > that I magnified his merit and forgot to mention the role
> > of Patric
On Mon, Jan 22, 2007 at 10:19:18AM +0300, Michael Tokarev wrote:
...
> I was only running tcpdump - yes, it was running almost the
> whole day, with different options. I did almost nothing.
>
> You over-estimate my contribution, really ;)
>
> The very good thing is that this bug is now found, an
On Fri, Jan 19, 2007 at 03:08:20PM +0100, Jarek Poplawski wrote:
...
> You are welcome! But you probably didn't read this with
> attention: if it works, you should thank mainly to that
> other guy...
>
> Btw. I can't remember I've seen such ferocious testing
On Sat, Jan 20, 2007 at 08:10:27AM +1100, Herbert Xu wrote:
> On Fri, Jan 19, 2007 at 12:06:41PM +0100, Jarek Poplawski wrote:
> >
> > [PATCH][NET] tcp_output: rare bad TCP checksum with 2.6.19
> >
> > The patch "Replace CHECKSUM_HW by CHECKSUM_PARTIAL/C
On Fri, Jan 19, 2007 at 01:14:52PM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> > Here is my patch proposal. If I'm not totally wrong,
> > there is a possibility that, during collapsing, empty
> > skb with FIN is added to "normal" packet an
On Fri, Jan 19, 2007 at 04:20:01PM +0300, Michael Tokarev wrote:
...
> Well.. I just tried it - with this patch applied, no more bad checksums
> are shown. Tried from the network that triggers it most reliable - and
> wasn't able to reproduce the bad behavior.
>
> I'm running a tcpdump right now
its ip_summed field to CHECKSUM_NONE.
Regards,
Jarek P.
PS: probably there are also other possibilities...
---
[PATCH][NET] tcp_output: rare bad TCP checksum with 2.6.19
The patch "Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE"
changed to unconditional copying of ip_summed f
On Wed, Jan 17, 2007 at 09:14:20AM +0100, Jarek Poplawski wrote:
...
> I've a look at this once more and have one more doubt:
> probably it's some other ip6 trick again, but why this
> default router doesn't have "normal" address in the
> same segment (2001
On Thu, Jan 11, 2007 at 02:08:16PM +0100, Bernhard Schmidt wrote:
> Jarek Poplawski wrote:
>
> >>ip -6 route:
> >>2001:4ca0:0:f000::/64 dev eth0 proto kernel metric 256 expires
> >>86322sec mtu 1500 advmss 1440 fragtimeout 4294967295
> >>fe80::/64 dev
On Tue, Jan 16, 2007 at 01:28:52PM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> > On Tue, Jan 16, 2007 at 11:19:34AM +0100, Patrick McHardy wrote:
> > ...
> >
> >>Right, this changes it from long (tc_core_usec2tick) to unsigned
> >>int
On Tue, Jan 16, 2007 at 11:19:34AM +0100, Patrick McHardy wrote:
...
> Right, this changes it from long (tc_core_usec2tick) to unsigned
> int. It doesn't make any difference though, ...
... if we count out reading_time_2tick, of course.
Jarek P.
-
To unsubscribe from this list: send the line "un
On 10-01-2007 11:01, Patrick McHardy wrote:
> [IPROUTE]: Use tc_calc_xmittime where appropriate
>
> Replace expressions of the form "100 * size/rate" by tc_calc_xmittime().
> The CBQ case deserves an extra comment: when called with bnwd=rate
> tc_cbq_calc_maxidle behaves identical to tc_calc_x
On 10-01-2007 11:01, Patrick McHardy wrote:
> [IPROUTE]: Introduce tc_calc_xmitsize and use where appropriate
>
> Add tc_calc_xmitsize() as complement to tc_calc_xmittime(), which calculates
> the size that can be transmitted at a given rate during a given time.
>
> Replace all expressions of the
On 10-01-2007 11:01, Patrick McHardy wrote:
> [IPROUTE]: Replace "usec" by "time" in function names
>
> Rename functions containing "usec" since they don't necessarily return
> usec units anymore.
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
>
> ---
...
> diff --git a/tc/q_cbq.c b/tc/q
On 09-01-2007 17:08, [EMAIL PROTECTED] wrote:
> Hello,
>
> I have been trying to get the RED qdisc and ECN to work for the past few weeks
> and all my experiments have failed. Here is the setup I am using.
>
> Src -- R1 -- R2 -- Dst
>
> Between Src and R1 is a 100Mbps link and between R1 and R2
On Thu, Jan 11, 2007 at 09:42:13AM -0800, Stephen Hemminger wrote:
> Paul McKenney has given lots of talks on RCU see:
> http://www.rdrop.com/users/paulmck/RCU/
>
> and look in Documentation/RCU
I've read a lot of this but it's sometimes confusing e.g.:
>From Documentation/RCU/checklist.t
On 10-01-2007 01:23, Bernhard Schmidt wrote:
> On Tue, Jan 09, 2007 at 08:36:24PM +0100, Bernhard Schmidt wrote:
...
>> I'm having a really ugly problem I'm trying to pinpoint, but failed so
>> far. I'm neither completely convinced it is not related to my local
>> setup(s), nor do I have any clue h
On Thu, Jan 11, 2007 at 01:27:55AM -0800, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Thu, 11 Jan 2007 09:39:34 +0100
>
> > Sure, but is this even legal to be preempted during
> > reading or modifying rcu list or be blocked while
> &
rly locked: mp->tx_desc_count in while condition isn't
protected at all. Below I attach a patch proposal but I'm
not sure some irq off or spin_lock isn't also needed
elswere. If it's only locking it would be suitable to do
the test with a kernel compiled without PREEMPT and SMP
On Thu, Jan 11, 2007 at 09:35:26AM +0100, Jarek Poplawski wrote:
> On Thu, Jan 11, 2007 at 09:29:58AM +0100, Jarek Poplawski wrote:
> > On Wed, Jan 10, 2007 at 11:40:35PM -0800, David Miller wrote:
> > > From: Jarek Poplawski <[EMAIL PROTECTED]>
> > > Date
On Thu, Jan 11, 2007 at 09:29:58AM +0100, Jarek Poplawski wrote:
> On Wed, Jan 10, 2007 at 11:40:35PM -0800, David Miller wrote:
> > From: Jarek Poplawski <[EMAIL PROTECTED]>
> > Date: Thu, 11 Jan 2007 08:24:28 +0100
> >
> > > Yesterday I did what I should do
On Wed, Jan 10, 2007 at 11:40:35PM -0800, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Thu, 11 Jan 2007 08:24:28 +0100
>
> > Yesterday I did what I should do earlier - checked
> > this simple way, with printk, and now I have no doubts
&g
On Wed, Jan 10, 2007 at 12:01:23PM -0800, Stephen Hemminger wrote:
...
> Don't rely on books too heavily, they can get out of date
> with a simple code change.
I've tried to find this in the code at the beginning
and got mislead by the path with PREEMPT_BKL.
I think the books are necessary to get
On Wed, Jan 10, 2007 at 08:13:57AM -0500, Paul Moore wrote:
> On Wednesday 10 January 2007 5:01 am, Jarek Poplawski wrote:
> > On Tue, Jan 09, 2007 at 09:26:46AM -0500, Paul Moore wrote:
> > > On Tuesday 09 January 2007 3:43 am, Jarek Poplawski wrote:
> > > > ... But
On Wed, Jan 10, 2007 at 10:04:11AM +0100, Jarek Poplawski wrote:
...
> It looks like you're talking about the right thing
> and I'm a fool again! Now I try to find why I even
> had to pay for this. I read again and again adequate
> chapters from R. Love and C. Benvenuti'
On Tue, Jan 09, 2007 at 09:26:46AM -0500, Paul Moore wrote:
> On Tuesday 09 January 2007 3:43 am, Jarek Poplawski wrote:
> > ... But if you consider this code will probably become classical
> > and will be read, quoted and teached next 1000 years, then the style
> > could matt
On Tue, Jan 09, 2007 at 09:10:45AM +0100, Jarek Poplawski wrote:
> On Mon, Jan 08, 2007 at 10:03:50AM -0800, Stephen Hemminger wrote:
...
> > > > * Must be invoked with RCU read lock (no preempt)
> > > > */
> > > > struct net_device *__fi
On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote:
...
> I suspected both and changed both the disk and the ram for quality
> parts, that I tested afterwards. Both passed thorough tests.
>
> Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps),
> works absolutely fine.
I
On Tue, Jan 09, 2007 at 11:56:59AM +0100, Thibaut VARENE wrote:
...
> I'm suspecting the driver, but I'm not a specialist :)
No problem, me also!
I've also suspected the driver, looked at the
code, found nothing yet (as expected), but this
info about exception in malloc, introduces some
doubts...
On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote:
...
> Finally, using the other NIC on the box (a VIA Rhine II, 100Mbps),
> works absolutely fine.
... and the speed could matter here too ...
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of
On Tue, Jan 09, 2007 at 11:27:59AM +0100, Thibaut VARENE wrote:
...
> I suspected both and changed both the disk and the ram for quality
> parts, that I tested afterwards. Both passed thorough tests.
You wrote about half an hour, so overheating was also
considered, I presume.
> Finally, using the
On 05-01-2007 20:03, Thibaut VARENE wrote:
> Hi,
>
> I've been experiencing this bug on my Pegasos II (PPC G4 1GHz, 512M
...
> [C7F6FA60] [C0012498] ret_from_except+0x0/0x14
>
> --- Exception: 501 at __kmalloc+0x30/0xc0
>
>
On Mon, Jan 08, 2007 at 09:47:29AM -0500, Paul Moore wrote:
...
> I guess it all depends on who is reading it ;)
Sure! I only had a feeling your way is maybe slightly
less often used so I wanted some opinion.
> Personally, I don't care too
> much either way as long as it is fixed.
Yes, you've d
On Mon, Jan 08, 2007 at 10:03:50AM -0800, Stephen Hemminger wrote:
> On Mon, 08 Jan 2007 08:57:10 -0800
> Ben Greear <[EMAIL PROTECTED]> wrote:
>
> > Jarek Poplawski wrote:
> > > On Fri, Jan 05, 2007 at 12:33:43PM -0800, Ben Greear wrote:
> > > ...
> &
On 04-01-2007 21:04, Paul Moore wrote:
...
> +++ net-2.6.20_bugfix_2/net/ipv4/af_inet.c
> @@ -305,7 +305,7 @@ lookup_protocol:
> sk->sk_reuse = 1;
>
> inet = inet_sk(sk);
> - inet->is_icsk = INET_PROTOSW_ICSK & answer_flags;
> + inet->is_icsk = (INET_PROTOSW_ICSK & ans
On Thu, Jan 04, 2007 at 02:51:55PM +0100, Jarek Poplawski wrote:
>
> Hello,
>
> Below I attach a patch proposal.
It seems I wasted some time...
I wonder if there is any reason to forward netfilter
bugs to netdev if patches from netfilter aren't cc-d
here? It seems ne
On Fri, Jan 05, 2007 at 12:33:43PM -0800, Ben Greear wrote:
...
> So, I do believe this was the problem we were hitting, and it seems fixed.
Congratulations!
But I can see one strange thing in vlan.c:
/* Must be invoked with RCU read lock (no preempt) */
static struct vlan_group *__vlan_find_gro
On Thu, Jan 04, 2007 at 09:04:29AM -0800, Ben Greear wrote:
> Jarek Poplawski wrote:
> >On Thu, Jan 04, 2007 at 09:27:07PM +1100, Herbert Xu wrote:
> >
> >>On Thu, Jan 04, 2007 at 09:50:14AM +0100, Jarek Poplawski wrote:
> >>
> >>>Could
On Fri, Jan 05, 2007 at 10:23:53PM +1100, Herbert Xu wrote:
> On Fri, Jan 05, 2007 at 12:19:10PM +0100, Jarek Poplawski wrote:
> >
> > Why me? (I didn't spoil this!)
>
> You spotted the problem, so it's only fair that you get the credit :)
Strange... It recalls m
On Fri, Jan 05, 2007 at 08:38:47PM +1100, Herbert Xu wrote:
> On Fri, Jan 05, 2007 at 07:38:44AM +0100, Jarek Poplawski wrote:
> >
> > I'd only suggest to change "goto out;" to
> > "return NULL;" at the end of inetdev_init because
> > now
On Thu, Jan 04, 2007 at 04:16:20PM +, Jon Maloy wrote:
> Regards
> ///jon
>
> Jarek Poplawski wrote:
>
> >
> >I know lockdep is sometimes
> >too careful but nevertheless some change is needed
> >to fix a real bug or give additional information
> >
On Thu, Jan 04, 2007 at 12:33:33PM -0800, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Thu, 04 Jan 2007 17:26:27 +1100
>
> > David Stevens <[EMAIL PROTECTED]> wrote:
> > >You're right, I don't know whether it'll fix the problem Ben saw
> > > or not, but it looks like
36.483030] EIP: [] device_cmp+0x1b/0x2e [ipt_MASQUERADE] SS:ESP
> 0068:de6d4e90
> [ 336.483183] <0>Kernel panic - not syncing: Fatal exception in interrupt
---
Subject: [PATCH] netfilter: ipt_MASQUERADE: NULL check in device_cmp
nfct_nat can return NULL so check is needed in devi
On Wed, Jan 03, 2007 at 11:16:59PM +, Jon Maloy wrote:
> See my comments below.
> Regards
> ///jon
>
> Jarek Poplawski wrote:
>
> >..
> >
> >Maybe I misinterpret this but, IMHO lockdep
> >complains about locks acquired in different
> &
On Wed, Jan 03, 2007 at 04:53:58PM +, Sid Boyce wrote:
...
> It seems >=2.6.19 and the SuSEfirewall are incompatible.
Actually, many programs could be incomapatible with
newer kernel versions, so sometimes upgrades or at
least recompilations are needed.
...
> There is still the problem whe
On Thu, Jan 04, 2007 at 09:27:07PM +1100, Herbert Xu wrote:
> On Thu, Jan 04, 2007 at 09:50:14AM +0100, Jarek Poplawski wrote:
> >
> > Could you explain? I can see some inet_rtm_newaddr
> > interrupted. For me it could be e.g.:
> >
> > after
> > vconfig add
On Thu, Jan 04, 2007 at 07:29:30PM +1100, Herbert Xu wrote:
> On Thu, Jan 04, 2007 at 09:03:51AM +0100, Jarek Poplawski wrote:
> >
> > I doubt this is the right solution. It certainly
> > could fix this particular situation but my main
> > point was packets shouldn&#x
On Thu, Jan 04, 2007 at 05:26:27PM +1100, Herbert Xu wrote:
> David Stevens <[EMAIL PROTECTED]> wrote:
> >You're right, I don't know whether it'll fix the problem Ben saw
> > or not, but it looks like the original code can do a receive before the
> > in_device is fully initialized, and that
On Tue, Jan 02, 2007 at 03:32:01PM +, Sid Boyce wrote:
> Jarek Poplawski wrote:
...
> >If you could send full ifconfig, route -n (or ip route
> >if you use additional tables) and tcpdump (all packets)
> >from both boxes while pinging each other and a few words
> >
On Wed, Jan 03, 2007 at 09:07:11AM +0100, Jarek Poplawski wrote:
> On Tue, Jan 02, 2007 at 03:35:39PM -0800, David Stevens wrote:
> > I've looked at this a little too -- it'd be nice to know who holds
> > the write lock.
>
> If you mean mc_list_lock - probably nobo
On Tue, Jan 02, 2007 at 03:35:39PM -0800, David Stevens wrote:
> I've looked at this a little too -- it'd be nice to know who holds
> the write lock.
If you mean mc_list_lock - probably nobody - it's
not initialized (so the timers) for this in_device
and rtnl mutex is preempted by irq.
Actually I
On 02-01-2007 08:51, David Miller wrote:
> From: Mariusz Kozlowski <[EMAIL PROTECTED]>
> Date: Tue, 2 Jan 2007 00:55:51 +0100
>
>> On error we should start freeing resources at [i-1] not [i-2].
>>
>> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
>
> Patch applied, thanks Mariusz.
>
>> dif
On Tue, Jan 02, 2007 at 09:23:02AM +0100, Jarek Poplawski wrote:
> On Tue, Jan 02, 2007 at 08:39:09AM +0100, Jarek Poplawski wrote:
> ...
> > The main thing is the possibility of processing
> > skb with not entirely open source dev which isn't
> > expected (and checked
On Tue, Jan 02, 2007 at 08:39:09AM +0100, Jarek Poplawski wrote:
...
> It is hard to say what kind of bug to expect
> because at the same time other net_rx_action
> with the same vlan dev could take place on
> other processor and this inetdev_init could
> do more.
Sorry! inetdev_i
On Mon, Jan 01, 2007 at 09:00:05PM -0800, Ben Greear wrote:
> I finally had time to look through the code in this backtrace in
> detail. I think it *could*
> be a race between ip_rcv and inetdev_init, but I am not certain. Other
> than that, I'm real
> low on ideas. I found a few more stack tr
On Wed, Dec 27, 2006 at 08:16:10AM -0800, Ben Greear wrote:
> Jarek Poplawski wrote:
> >On Fri, Dec 22, 2006 at 06:05:18AM -0800, Ben Greear wrote:
> >>Jarek Poplawski wrote:
> >>>On Fri, Dec 22, 2006 at 08:13:08AM +0100, Jarek Poplawski wrote:
> >>
On Wed, Dec 27, 2006 at 08:16:10AM -0800, Ben Greear wrote:
...
> The system hangs and does not recover (well, a few processes
> continue on the other processor for a few minutes before they
> too deadlock...)
>
> I am guessing this problem has been around for a while, but it
> is only triggered w
d
two places where return values from
tipc_ref_lock() and tipc_port_lock() are not
checked, so I attach a patch proposal for
this (compiled but not tested):
Regards,
Jarek P.
---
[PATCH] tipc: checking returns from locking functions
Checking of return values from tipc_ref_lock()
and tipc_port_
On Fri, Dec 22, 2006 at 06:05:18AM -0800, Ben Greear wrote:
> Jarek Poplawski wrote:
> >On Fri, Dec 22, 2006 at 08:13:08AM +0100, Jarek Poplawski wrote:
> >>On 20-12-2006 03:13, Ben Greear wrote:
> >>>This is from 2.6.18.2 kernel with my patch set. The MAC
On Fri, Dec 22, 2006 at 10:16:30PM +1100, Herbert Xu wrote:
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> >
> > [PATCH] igmp: spin_lock_bh in timer
> >
> > igmp_timer_expire() uses spin_lock(&im->lock)
> > but this lock is also taken by other
On Fri, Dec 22, 2006 at 08:13:08AM +0100, Jarek Poplawski wrote:
> [PATCH] igmp: spin_lock_bh in timer
>
> igmp_timer_expire() uses spin_lock(&im->lock)
> but this lock is also taken by other igmp timers,
> so it should be changed to bh version.
... but according to theory
On Fri, Dec 22, 2006 at 08:13:08AM +0100, Jarek Poplawski wrote:
> On 20-12-2006 03:13, Ben Greear wrote:
> > This is from 2.6.18.2 kernel with my patch set. The MAC-VLANs are in
> > active use.
> > From the backtrace, I am thinking this might be a generic problem,
>
x27;ll upgrade to 2.6.19 or higher.
Regards,
Jarek P.
---
[PATCH] igmp: spin_lock_bh in timer
igmp_timer_expire() uses spin_lock(&im->lock)
but this lock is also taken by other igmp timers,
so it should be changed to bh version.
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
On 04-12-2006 16:34, Patrick McHardy wrote:
> Fix a regression from my nfmark mask patch for cls_fw.
>
> Thomas, Jamal, do you have an idea what this "old method" stuff
> is used for? It seems it is only used during the below mentioned
> race.
>
Sorry for eavesdropping, but have a look at htb_cl
On Thu, Nov 30, 2006 at 01:26:34PM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> > [NET_SCHED] sch_htb:
> >
> > [PATCH 2.6.19-rc6 with "Fix endless loops" set of patches]
> >
> > - turn intermediate classes into leaves again when their
&g
On Wed, Nov 29, 2006 at 04:16:06PM +0100, Krzysztof Halasa wrote:
> Krzysztof Halasa <[EMAIL PROTECTED]> writes:
>
> > I wound't care less btw.
>
> s/wound/couldn/, eh those foreign languages...
So, you say, you don't care about David Miller's credits?
It isn't nice. He could be very disappointe
On 29-11-2006 08:49, Herbert Xu wrote:
> Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>> =
>> [ INFO: possible irq lock inversion dependency detected ]
>> 2.6.19-rc6 #4
>> -
>> nc/1854 just
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,
[NET_SCHED] sch_htb:
[PATCH 2.6.19-rc6 with "Fix endless loops" set of patches]
- turn intermediate classes into leaves again when their
last child is deleted (struct htb_class changed)
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.19-rc6-en
- a redundant instruction removed from cbq_deactivate_class
PS: probably htb_deactivate in htb_delete and
cbq_deactivate_class in cbq_delete are also
redundant now.
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp linux-2.6.19-rc6-endless-/net/sched/sch_cbq.c
linux-2.6.19-
On Mon, Nov 27, 2006 at 11:12:23AM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> > Here is a trial to do something suggested by Patrick McHardy.
> >
> > [NET_SCHED] sch_htb:
> >
> > - turn intermediate classes into leaves again when their last chil
On Mon, Nov 27, 2006 at 10:55:39AM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
> > Here are some fixes proposals suggested by Patrick McHardy.
> >
> > [NET_SCHED] sch_cbq:
> >
> > - deactivating of active classes when grafting
> >
> &
consistency with htb_delete and htb_destroy) - my own suggestion
PS: qdisc_reset added to htb_delete by P. McHardy's patch: "perform qlen
adjustment immediately in ->delete" should be reconsidered.
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp lin
ion removed from cbq_deactivate_class (my own
suggestion)
PS: - purging of queue and deactivating of active classes
when attaching a new child - not done (according to man, CBQ can carry
packets in any type of nodes).
Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]>
---
diff -Nurp lin
On Fri, Nov 24, 2006 at 02:07:08PM +0100, Patrick McHardy wrote:
> Jarek Poplawski wrote:
...
> > Probably it is as usual something with my eyes but
> > it seems cbq needs in cbq_delete or cbq_destroy_class
> > some treatment (about qdisc_destroy) similar to htb.
>
>
On Thu, Nov 16, 2006 at 11:25:01PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 17 Nov 2006, Jarek Poplawski wrote:
> >
> > With great astonishment I've found none of
> > these "networking" names in the CREDITS file:
> > Stephen Hemminger, Thomas
Hello,
With great astonishment I've found none of
these "networking" names in the CREDITS file:
Stephen Hemminger, Thomas Graf, Alexey Kuznetsov,
Andrew Morton, Pedro Roque, Jamal Hadi Salim,
Herbert Xu etc.
IMHO there is something wrong with the hitherto
way of updating this file and probably so
On Mon, Nov 13, 2006 at 02:58:17PM -0500, Paul Moore wrote:
> Jarek Poplawski wrote:
> > @@ -586,7 +586,7 @@
> >goto failure;
> >}
> >/* add a DOC_EXMPL_A_MSG attribute */
> > - rc = nla_put_string(skb, DOC_EXMPL_A_MSG, "Generic Netlink R
On Fri, Nov 10, 2006 at 06:36:42PM +0100, Thomas Graf wrote:
> * Jarek Poplawski <[EMAIL PROTECTED]> 2006-11-10 14:24
> > @@ -449,7 +449,7 @@
> >
> > The second step is to define the operations for the family, which we do by
> > creating at least one instance o
501 - 600 of 643 matches
Mail list logo
