On Fri, May 9, 2014 at 8:52 AM, Borislav Petkov <bp@xxxxxxxxx> wrote: > On Thu, May 08, 2014 at 03:37:19PM -0500, Thor Thayer wrote: >> Yes. Their reasoning is that they want to retain the rights and >> warranty language with the file (just in case the COPYING file >> changes). > > Ok, thanks for checking up on this. > >> Yes. I tested using edac_core.edac_mc_panic_on_ue=1 from the command >> line and it worked fine. I'll add a comment to clarify. BTW, thanks >> for your help on that. > > Sure, but the question still remains: do you want to panic on > uncorrectable errors by default or want the user to decide? I guess this > is something you can answer for your hardware... Yes, good point. Our hardware can't recover from Double Bit Errors so I'll go back to the panic() in that path. I like the flexibility of the command line parameter though... > >> I considered using "volatile" variables, but decided against it after >> I read Documentation/volatile-considered-harmful.txt and my situation >> doesn't fit into the exemptions. Is there a better way to handle this? > > Off the top of my head, I'd first look at compiler asm output to > check what my compiler does with those writes and then take a look at > employing the ACCESS_ONCE macro or something similar where we use the > asm volatile() as an optimization stop for the compiler, among others. > > And then I'll look at asm again to make sure it does what it is supposed > to do. Something to that effect, in any case... > > HTH. The reads aren't optimized out now but I'd like to protect against future optimization changes. I implemented ACCESS_ONCE and checked the resulting asm output - it looks clean. Thanks. > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
