Klaus Hitschler wrote: >> For the time being, I tend to fix just the problem for the system where >> is shows up. It would be nice if we could reproduce it somehow. Klaus, >> on what hardware did you realize that problem? > > On multiple x86 multi-core machines. The scenario was always the same. The > users got lots of receive data and did send data with a low frequency. In > this > case sometimes the initial write (triggered in the direct control path of a > ioctl) got lost and following writes become stalled since no transmit-ready > interrupt was raised. I managed to reproduce the fault multiple times. > > The write stall did not happen on single core machines.
Is this a true SMP issue or is the probability on (today's) UP machines just lower? What about PREEMPT_RT on UP system? With PREEMPT_RT you have threaded hardware interrupts. > It is not enough to add a delay since you cannot determine when the register > is accessed by another core in follow of a interrupt. Even Softirq code can > be > interrupted by Hardirqs. > > OK. Most PCI systems cannot run the desgined 33 nsec BUS cycles. But the > situation is not less serious with e.g. 66 nsec, 99 nsec ... cheers, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
