Before the patch goes upstream I need it tested so I know if it fixes
the actual issue or not.
We have been using the rcu_sched patch and the cond_resched patch together
(both attached) since November 3rd on 3.17.2 without any bcache
backtraces. bcache is running in writeback mode. The server is
predominantly write-only with relatively few reads.
Is the rcu_sched patch supposed to help the same or a totally different
problem? Means: should I also apply it, rebuild the module and reboot
(resetting the test time to zero :-)
The second backtrace mentioned on this link is the issue that I believe is
fixed with the rcu_sched patch:
https://www.mail-archive.com/linux-bcache@xxxxxxxxxxxxxxx/msg02623.html
The error starts with a message like "INFO: rcu_sched self-detected stall
on CPU"
-Eric
I had the "deadly" soft lockup once per week since updating to
3.16/3.17, so I can only tell if it might help in two weeks earliest.
To sum up, the attached two patches (plus the for-jens pull) have fixed all
of our bcache problems since 3.14.y. These patches on 3.17.2 seem quite stable.
That's good to hear :-)
Best regards,
Stefan
--
Stefan Seyfried
Linux Consultant & Developer -- GPG Key: 0x731B665B
B1 Systems GmbH
Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
