On Mon, Jan 4, 2016 at 2:04 PM, Joel Sherrill <j...@rtems.org> wrote:
> > > On Mon, Jan 4, 2016 at 3:48 AM, Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> >> >> On 23/12/15 22:22, Marcos Díaz wrote: >> >>> That patch didn't work, >>> one reason is that it has a mistake: >>> in kern_tc.c you defined this macro: >>> >>> #define _Timecounter_Release(lock_context) \ >>> + *_ISR_lock_ISR_disable_and_acquire*(&_Timecounter_Lock, lock_context) >>> >>> I think you meant: >>> >>> *_ISR_lock_Release_and_ISR_enable*(&_Timecounter_Lock, lock_context) >>> >> >> Its strange, that this didn't lead to failures in Qemu. >> >> > Qemu doesn't do cycle or instruction level simulation. > I'm not sure if I fully understand this statement, but FWIW qemu can do per-instruction emulation, in fact I fixed one 7 years ago https://lists.nongnu.org/archive/html/qemu-devel/2009-08/msg01153.html > It does blocks of instructions between potential control flow points. > Perhaps this is enough to make real hardware and the simulation behave > differently in this case. > > For sure, it reduces the potential race conditions showing up in SMP > applications since it is alternating blocks of instructions on each > simulated core. > > >> >>> The other reason is that as I said, the driver checks for the flag >>> PENDSTSET of the ICSR register, and I think this approach is wrong, because >>> that flag goes down when the tick interrupt is attended. I used the >>> solution I proposed before, but I'm still seeing some errors. I'll let you >>> know what I find. >>> >> >> Would you mind testing the attached second version of the patch? >> >> -- >> Sebastian Huber, embedded brains GmbH >> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany >> Phone : +49 89 189 47 41-16 >> Fax : +49 89 189 47 41-09 >> E-Mail : sebastian.hu...@embedded-brains.de >> PGP : Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel >> > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype: dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
