about TBROK causing test failure

[qqxlt]

Some test cases fail. It can be seen from the test process that it is caused by TBROK. Repeated testing of the test case has a probability of passing. Can this count as failure of the test case?

for example

[metan-ucw]

I/O errors from memcg files looks like a something is wrong with your kernel.

Also TBROK means that test setup has failed and something is broken, it's not the cause but rather end result of broken system.

[qqxlt]

Repeated testing of the test case has a probability of passing.

Repeated testing of the test case has a probability of passing. Do you still need to pay attention to such mistakes?

[metan-ucw]

Of course, if test fails only once in ten or even in hundred runs there is likely problem somewhere. Linux kernel is massively parallel and in most of the cases you need right timing for a race condition to happen. Sometimes the probability of hitting the bug is really small, but that does not mean that it's not there.

[qqxlt]

Of course, if test fails only once in ten or even in hundred runs there is likely problem somewhere. Linux kernel is massively parallel and in most of the cases you need right timing for a race condition to happen. Sometimes the probability of hitting the bug is really small, but that does not mean that it's not there.

Thanks

[qqxlt]

Of course, if test fails only once in ten or even in hundred runs there is likely problem somewhere. Linux kernel is massively parallel and in most of the cases you need right timing for a race condition to happen. Sometimes the probability of hitting the bug is really small, but that does not mean that it's not there.

Thanks

Is there any good debugging method for such problems?

[metan-ucw]

I'm afraid there isn't easy manual to follow. Linux kernel is a complex beast and it takes time to understand its internals. I would have started with isolating the exact failure i.e. figuring out what step went wrong. Once you have idea what exactly went wrong you can start with debugging. However if this is a kernel race condition it takes years to acquire right skill set to be able to pinpoint the problem.

[qqxlt]

I'm afraid there isn't easy manual to follow. Linux kernel is a complex beast and it takes time to understand its internals. I would have started with isolating the exact failure i.e. figuring out what step went wrong. Once you have idea what exactly went wrong you can start with debugging. However if this is a kernel race condition it takes years to acquire right skill set to be able to pinpoint the problem.

Thanks