On Friday February 25, brad@wasp.net.au wrote:
Turning on debugging in raid6main.c and md.c make it much harder to hit. So I'm assuming something
timing related.
raid6d --> md_check_recovery --> generic_make_request --> make_request --> get_active_stripe
Yes, there is a real problem here. I see if I can figure out the best
way to remedy it...
However I think you reported this problem against a non "-mm" kernel,
and the path from md_check_recovery to generic_make_requests only
exists in "-mm".
Could you please confirm if there is a problem with
2.6.11-rc4-bk4->bk10
as reported, and whether it seems to be the same problem.
Thanks,
NeilBrown
Neil Brown wrote:
On Friday February 25, brad@wasp.net.au wrote:
quoted
Turning on debugging in raid6main.c and md.c make it much harder to hit. So I'm assuming something
timing related.
raid6d --> md_check_recovery --> generic_make_request --> make_request --> get_active_stripe
Yes, there is a real problem here. I see if I can figure out the best
way to remedy it...
However I think you reported this problem against a non "-mm" kernel,
and the path from md_check_recovery to generic_make_requests only
exists in "-mm".
Could you please confirm if there is a problem with
2.6.11-rc4-bk4->bk10
There is (was). I have three kernels I was testing against. 2.6.11-rc4-bk4, 2.6.11-rc4-bk10 and
2.6.11-rc4-mm1. I moved onto 2.6.11-rc4-mm1 for my main debugging (inserting lots of printks and
generally doing stuff that was going to crash). I hope to reproduce the faults against the vanilla
2.6.11-rc4 kernels and I'm now testing with 2.6.11-rc5-bk2.
As per the original bug report, 2.6.11-rc4-bk(4/10) locked in [<c0268574>]
get_active_stripe+0x224/0x260. Although unlike -mm1 I'm not sure of the sequence of events that
caused it and it's not anywhere as easy to hit. I am willing to investigate as time allows however.
Testing 2.6.11-rc5-bk2 and it of course is flatly refusing to misbehave. I'll keep beating on it for
a couple of days and after writing 3TB with 2.6.11-rc5-bk2, I'll go back to the older kernels and
try and reproduce the failure there. It *did* lockup 4 times in a row in get_active_stripe on the
older non -mm kernels.
Regards,
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
Neil Brown wrote:
Could you please confirm if there is a problem with
2.6.11-rc4-bk4->bk10
as reported, and whether it seems to be the same problem.
Ok.. are we all ready? I had applied your development patches to all my vanilla 2.6.11-rc4-*
kernels. Thus they all exhibited the same problem in the same way as -mm1. <Smacks forehead against
wall repeatedly>
I had applied the patch to correct the looping resync issue with too many failed drives, and just
continued and applied all the other patches also.
I have been unable to reproduce the fault using a vanilla 2.6.11-rc5-bk2 kernel.
Oh well, at least we now know about a bug in the -mm patches.
Regards,
Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams