Sebastian Smolorz wrote: > Stéphane ANCELOT wrote: >>> IIRC, there is no possibility to detect a "normal" bus error >>> (acknowledge) appearing during normal operation from the one occuring >>> when the cable is plugged off. The best indication is a high number of >>> consecutive BEIs. >> I do not agree : >> case normal : >> In normal bus error condition, if error repeats the chip will go to >> busoff state (unfortunately I don't know how to simulate this...) >> >> case unplugged (easy to simulate): >> when the cable is not plugged it will not go to busoff condition. > > I know that. Unfortunately, you took my above answer out of context. I > replied > to: > >> What about something like option 3: After the first error occurred that >> may mark the beginning of a flood, disable that error interrupt until >> the next stop/start cycle or the user has read the event? > > I was referring to *one* bus error. If one bus error occurs how will the > driver know it is the beginning of a flood due to an unplugged cable? It can > only tell after serveral consecutive ones.
As damn SJA1000 doesn't seem to help us here, I was suggesting to play safe: disable that particular IRQ source until administrator reset or some task reads the generated error frame AND (that's probably required too) continues to ask for the next one. The latter condition would allow the error frame reader to fully control the IRQ rate. Note that this is not just about avoiding total lock-up. Even a specific period of an abnormal IRQ load can kill an RT system. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
