Putting for discussion "__qdisc_run" bug - strange application-dependant error

Putting for discussion "__qdisc_run" bug - strange application-dependant error

[Panadero Pizza]

Hello netdev group,

I would like to put for discussion, if a bug in the __qdsic_run function could explain the problem I have described in my post "Kernel networking problem (>=2.6.24.7)" two days ago.

"__qdisc_run" is the last common function in the kernel traces I receive for the kernels:

2.6.24.7
2.6.27.12

with a multi-threaded software, using fputc, putc, puts - calls, mixed with fflush()-calls on a remote file, opened on a cifs-handle. (Errors occur extremely seldom, although the software is running for hours - day after day)

I don't receive the error with other standard software (e.g. "dd"), writing to a file on the same cifs-handle/session and more interesting:
The error does not occur with the afore-mentioned multi-threaded program (or any other software), using a

2.6.16.62

kernel.

I have found that from 2.6.24.x on, the __qdisc_run function has been made preemptible and this feature has been enabled for the realization of the afore-said 2.6.24.7 and 2.6.27.12 kernels.

Though 2.6.16.62 solves my problem, I am offering participation in finding a solution for this (which should be fixed, if it is a kernel bug).

Best regards,
David


      

Re: Putting for discussion "__qdisc_run" bug - strange application-dependant error

[Jarek Poplawski]

Panadero Pizza wrote, On 05/09/2009 09:55 PM:

> Hello netdev group,
> 
> I would like to put for discussion, if a bug in the __qdsic_run function could explain the problem I have described in my post "Kernel networking problem (>=2.6.24.7)" two days ago.
> 
> "__qdisc_run" is the last common function in the kernel traces I receive for the kernels:
> 
> 2.6.24.7
> 2.6.27.12
> 
> with a multi-threaded software, using fputc, putc, puts - calls, mixed with fflush()-calls on a remote file, opened on a cifs-handle. (Errors occur extremely seldom, although the software is running for hours - day after day)
> 
> I don't receive the error with other standard software (e.g. "dd"), writing to a file on the same cifs-handle/session and more interesting:
> The error does not occur with the afore-mentioned multi-threaded program (or any other software), using a
> 
> 2.6.16.62
> 
> kernel.
> 
> I have found that from 2.6.24.x on, the __qdisc_run function has been made preemptible and this feature has been enabled for the realization of the afore-said 2.6.24.7 and 2.6.27.12 kernels.
> 
> Though 2.6.16.62 solves my problem, I am offering participation in finding a solution for this (which should be fixed, if it is a kernel bug).
> 


Since you're suggesting the specific patch has broken this for you, could
you simply write if 2.6.24.4 (or 2.6.24.7 with "NET: Add preemption point
in qdisc_run" patch reverted) also solves your problem?

Btw., you've admitted the stack could be a problem; did you try to enable
any kernel debugging for this?

Cheers,
Jarek P.

PS: continuing the discussion within one thread and limiting line width
would make it easier to track this report.

Re: Putting for discussion "__qdisc_run" bug - strange application-dependant error

[Jarek Poplawski]

Jarek Poplawski wrote, On 05/10/2009 09:33 AM:

> Panadero Pizza wrote, On 05/09/2009 09:55 PM

...

>> I have found that from 2.6.24.x on, the __qdisc_run function has been made preemptible and this feature has been enabled for the realization of the afore-said 2.6.24.7 and 2.6.27.12 kernels

...

> Since you're suggesting the specific patch has broken this for you, could
> you simply write if 2.6.24.4 (or 2.6.24.7 with "NET: Add preemption point
> in qdisc_run" patch reverted) also solves your problem?


Btw., let's make it clear: after this patch the __qdisc_run function hasn't
been made preemptible; it could simply exit before all work is finished and
schedule the rest for later.

Jarek P.

Re: Putting for discussion "__qdisc_run" bug - strange application-dependant error

[Panadero Pizza]

De: Jarek Poplawski

> Since you're suggesting the specific patch has broken this for you, could

> you simply write if 2.6.24.4 (or 2.6.24.7 with "NET: Add preemption point
> in qdisc_run" patch reverted) also solves your problem?

I'm now testing the 2.6.24.7 kernel with CONFIG_PREEMPT_NONE.
(If I knew how to easily revert the patch for the __qdisc_run function,
I would like to test it, too) ... 

> Btw., you've admitted the stack could be a problem; did you try to enable
> any kernel debugging for this?

Thanks for the hint! I have found the DEBUG_STACKOVERFLOW option,
which seems reasonable. Using it now, too.

Testing will now take some days, because errors are very seldom - I will
post my results here again.

Cheers,
David


      

Re: Putting for discussion "__qdisc_run" bug - strange application-dependant error

[Jarek Poplawski]

Panadero Pizza wrote, On 05/11/2009 01:33 PM:

> 
> De: Jarek Poplawski
> 
>> Since you're suggesting the specific patch has broken this for you, could
> 
>> you simply write if 2.6.24.4 (or 2.6.24.7 with "NET: Add preemption point
>> in qdisc_run" patch reverted) also solves your problem?
> 
> I'm now testing the 2.6.24.7 kernel with CONFIG_PREEMPT_NONE.
> (If I knew how to easily revert the patch for the __qdisc_run function,
> I would like to test it, too) ... 

You can try 2.6.24.4 which doesn't have this patch. But I doubt this
patch really matters here.

Jarek P.