Hi, > No, it's not. The root cause was a problem with the network softirq > and a network driver, the softirq ->49 was a temporary workaround > until we had enough information to find the real root cause. I wish > I'd never committed that change at all. Clear. Did not know it was already solved. I thought it was still an issue. This changes things :-) >> Race conditions that occur when a softirq preempts a related hardirq >> what the driver did not expect or was designed for. > > And making it the other way round hides the problem, which is even > worse. We want stuff to explode right away. 100% Agreed > You can run into the same > problem when the softirq holds a lock and the high prio irq thread > boosts it. OK. Thanks for the explanation. I see no reason any more why setting the prios default to 1 would be a bad thing. The rest of the configuration in that case can then indeed done be done by udev and other userland friends. Kind regards, Remy -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
