On Thu, Sep 28, 2006 at 07:20:00AM -0700, Stephen Hemminger wrote:
> On Thu, 28 Sep 2006 15:13:01 +0200
> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Sep 28, 2006 at 02:17:51PM +0200, Patrick McHardy wrote:
> > > [My mail provider is down, so responding "manually"]
> > >
> > > Jarek
On Thu, 28 Sep 2006 15:13:01 +0200
Jarek Poplawski <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 28, 2006 at 02:17:51PM +0200, Patrick McHardy wrote:
> > [My mail provider is down, so responding "manually"]
> >
> > Jarek Poplawski wrote:
> > > > [NET_SCHED]: Fix fallout from dev->qdisc RCU change
> >
On Thu, Sep 28, 2006 at 02:17:51PM +0200, Patrick McHardy wrote:
> [My mail provider is down, so responding "manually"]
>
> Jarek Poplawski wrote:
> > > [NET_SCHED]: Fix fallout from dev->qdisc RCU change
> >
> > Sorry again but I can't abstain from some doubts:
> >
> > ...
> > > diff --git a/net/
[My mail provider is down, so responding "manually"]
Jarek Poplawski wrote:
> > [NET_SCHED]: Fix fallout from dev->qdisc RCU change
>
> Sorry again but I can't abstain from some doubts:
>
> ...
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 14de297..4d891be 100644
> > --- a/net/core/de
On Wed, Sep 27, 2006 at 04:53:04PM -0700, David Miller wrote:
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Wed, 27 Sep 2006 14:07:04 +0200
...
> Although the HTB bug is post-2.6.18, the other issue has been
> around for a long time.
>
> Thus I'll need to submit the second patch to -stable,
On Wed, Sep 27, 2006 at 02:07:04PM +0200, Patrick McHardy wrote:
> Dave Jones wrote:
> > With this patch, I get no lockdep warnings, but the machine locks up
> > completely.
> > I hooked up a serial console, and found this..
> >
> >
> > u32 classifier
> > Performance counters on
> > inpu
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 27 Sep 2006 14:07:04 +0200
> Dave Jones wrote:
> > With this patch, I get no lockdep warnings, but the machine locks up
> > completely.
> > I hooked up a serial console, and found this..
> >
> >
> > u32 classifier
> > Performance counters
On Wed, Sep 27, 2006 at 02:07:04PM +0200, Patrick McHardy wrote:
> Dave Jones wrote:
> >
> > Call Trace:
> > [] show_trace+0xae/0x336
> > [] dump_stack+0x15/0x17
> > [] :sch_htb:htb_safe_rb_erase+0x3b/0x55
>
> I found the reason for this, it was an unrelated bug. I've attached
> the l
27 Eyl 2006 Çar 15:07 tarihinde, Patrick McHardy şunları yazmıştı:
> Dave Jones wrote:
> > With this patch, I get no lockdep warnings, but the machine locks up
> > completely. I hooked up a serial console, and found this..
> >
> >
> > u32 classifier
> > Performance counters on
> > input de
27 Eyl 2006 Çar 13:14 tarihinde şunları yazmıştınız:
> Dave Jones wrote:
> > With this patch, I get no lockdep warnings, but the machine locks up
> > completely. I hooked up a serial console, and found this..
> >
> >
> > u32 classifier
> > Performance counters on
> > input device check on
>
Dave Jones wrote:
> With this patch, I get no lockdep warnings, but the machine locks up
> completely.
> I hooked up a serial console, and found this..
>
>
> u32 classifier
> Performance counters on
> input device check on
> Actions configured
> BUG: warning at net/sched/sch_htb.c:
Dave Jones wrote:
> With this patch, I get no lockdep warnings, but the machine locks up
> completely.
> I hooked up a serial console, and found this..
>
>
> u32 classifier
> Performance counters on
> input device check on
> Actions configured
> BUG: warning at net/sched/sch_htb.c:
Jarek Poplawski wrote:
> Sorry for my not humble and simplistic opinion, but I'd dare
> to remind you are changing "stable" version and even without
> this lockups this patch would look very "serious". Why don't
> try to restore not-rcu version of qdisc_destroy which looks
> not lot to do.
I'm try
On Tue, Sep 26, 2006 at 05:20:34PM -0400, Dave Jones wrote:
> On Tue, Sep 26, 2006 at 06:15:21PM +0200, Patrick McHardy wrote:
> > Patrick McHardy wrote:
> > > jamal wrote:
> > >
> > >>Yes, that looks plausible. Can you try making those changes and see if
> > >>the warning is gone?
> > >
>
On Tue, Sep 26, 2006 at 06:15:21PM +0200, Patrick McHardy wrote:
> Patrick McHardy wrote:
> > jamal wrote:
> >
> >>Yes, that looks plausible. Can you try making those changes and see if
> >>the warning is gone?
> >
> >
> > I think this points to a bigger brokeness caused by the move of
>
Patrick McHardy wrote:
> jamal wrote:
>
>>Yes, that looks plausible. Can you try making those changes and see if
>>the warning is gone?
>
>
> I think this points to a bigger brokeness caused by the move of
> dev->qdisc to RCU. It means destruction of filters and actions doesn't
> necessarily happ
jamal wrote:
> On Mon, 2006-25-09 at 14:43 +0200, Jarek Poplawski wrote:
>
>
>>It's probably 2.6.18 and should change a little now (git4) but
>>IMHO main problem stays: it looks tcf_act_police_locate in
>>act_police.c was preempted in read_lock (tcf_police_lookup)
>>- now the same is possible in
On 25-09-2006 14:47, jamal wrote:
> On Mon, 2006-25-09 at 14:43 +0200, Jarek Poplawski wrote:
>
>> It's probably 2.6.18 and should change a little now (git4) but
>> IMHO main problem stays: it looks tcf_act_police_locate in
>> act_police.c was preempted in read_lock (tcf_police_lookup)
>> - now th
On Mon, 2006-25-09 at 14:43 +0200, Jarek Poplawski wrote:
> It's probably 2.6.18 and should change a little now (git4) but
> IMHO main problem stays: it looks tcf_act_police_locate in
> act_police.c was preempted in read_lock (tcf_police_lookup)
> - now the same is possible in tcf_hash_lookup. So
On 24-09-2006 23:29, Dave Jones wrote:
> =
> [ INFO: inconsistent lock state ]
> -
> inconsistent {softirq-on-R} -> {in-softirq-W} usage.
> swapper/0 [HC0[0]:SC1[2]:HE1:SE0] takes:
> (police_lock){-+--}, at: [] tcf_police_destroy+0x24
=
[ INFO: inconsistent lock state ]
-
inconsistent {softirq-on-R} -> {in-softirq-W} usage.
swapper/0 [HC0[0]:SC1[2]:HE1:SE0] takes:
(police_lock){-+--}, at: [] tcf_police_destroy+0x24/0x8f [act_police]
{softirq-on-R} state was regist
21 matches
Mail list logo