On Wed, Feb 27, 2008 at 11:06:31AM +0100, Zoltan Menyhart wrote: > Russ, > > Thank you for your remarks. > > I want to add a new mechanism for the MCA/INIT handlers to be able to > store their logs in a safe way. (No locks, no waiting,...) > This will be based on the two buffers and the atomic counter for each > of the MCA/INIT handlers. > > And I want to keep the existing mechanism when we are not in MCA/INIT > handlers' contexts. > > Using separate mechanisms, avoids MCA/INIT handlers interfering with > the interrupts and the polling. > > Should we receive too many CPEIs / CMCIs, chaining into polling, > may make us lose events. > > Should we receive too many recovered MCAs or INITs, there will > always be some logs lost. I want to keep the first and the last log. > The first one to know how it begins. > Why the last one? I've got a _feeling_ that the last one will have > accumulated consequences (whatever it is) of the preceding ones. Is this records per cpu or records total? In my experience, the first and last are somewhat random. Often, when we have received multiple MCA's due to an event, the telling record is in the middle of the heap and not easily determined without some experience with that type of event group. Is there any reasonable way to keep all the records or at least a larger group than just two. Russ, do you know what the max number of MCA/INIT records we would expect to see during a worst-case type event? Thanks, Robin - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Feb 27 21:54:54 2008
This archive was generated by hypermail 2.1.8 : 2008-02-27 21:55:09 EST