Thread (49 messages) 49 messages, 7 authors, 2007-06-04

Re: b44: regression in 2.6.22 (resend)

From: Maximilian Engelhardt <hidden>
Date: 2007-05-29 17:24:24
Also in: linux-wireless, lkml

On Tuesday 29 May 2007, Gary Zambrano wrote:
On Mon, 2007-05-28 at 13:55 -0700, Maximilian Engelhardt wrote:
quoted
On Monday 28 May 2007, Thomas Gleixner wrote:
quoted
On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
quoted
quoted
Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try
the following combinations on the kernel command line:

1) highres=off nohz=off (should be the same as your working config)
2) highres=off
3) nohz=off
I tested this with my 2.6.22-rc3 kernel, here are the results:

without any special boot parameters: problem does appear
highres=off nohz=off: problem does not appear
highres=off: problem does not appear
nohz=off: problem does appear
Is there any other strange behavior of the high res enabled kernel than
the b44 problem ?
I didn't notice anything.
quoted
quoted
I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution
Timer, but the high ping problem is still there.
Hmm, that's mysterious. Wild guess is that highres exposes the hidden
"feature" in a different way than rc2-mm1 does.
I think the bug in 2.6.21/22-rc3 is a different one that the one in
2.6.22-rc2-mm1, but that's also only a wild guess :)

I'll explain this a bit:
In 2.6.21/22-rc3 is the same b44 driver that has been in the stock
kernels for some time. With this driver and High Resolution Timer turned
on I get problems using iperf. The problems are that the systems becomes
really slow and unresponsive.  Michael Buesch thought this could be an
IRQ storm which sounds logical to me. This bug did never happen to me
before I startet the iperf test.
Can you please check to see if you notice anything out of the ordinary
using netperf in place of iperf in your high res timer on/off testbed?
ok, here are the results, I also had a look at the cpu kernel usage.
'good' means that the kernel responsiveness during the test was as I would 
expect it and I didn't notice any problems.

highres enabled:

netperf: 80%sy 15%si (good)
iperf: not really messureable (bad, problem described above)

highres disabled:

netperf: 80%sy 15%si (good)
iperf:  5%sy 30%hi 15%si (good)


for test tests I did run the following commands:
netperf -l 60 192.168.1.1
iperf -c 192.168.1.1 -r -t 60

I also tried to run iperf without any additional arguments (iperf -c 
192.168.1.1) on the problematic kernel but the result is the same as the 
command I wrote above.

Maxi

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help