On Fri, Jul 20, 2012 at 12:39:24AM +0000, Seiji Aguchi wrote: > > Thank you for describing this in detail. > > > Yes - if the OOPs is instrumental in the path leading to the hang/panic - then the OOPS is the first place to look for the root cause of > > the problem. But it will be a case by case analysis. > > Sometimes the OOPS might be unconnected. If possible we'd like to log more information to allow detective work to decide whether > > there is a connection. But as I mentioned above there are severe limits to how much better things are by storing more information. > > I understand the reason why you think 3 or 4 logs are reasonable. > There are some cases 2nd or 3rd oops is critical.... > > I have some enterprise customers who are sensitive for a software failure and specify panic_on_oops=1. > In this case, they don't need 3,4 logs. 2 logs are enough. > > So, kernel parameter should be as follows. > > Log_num =1 > - For users who want to hold just one log. > > Log_num=2 > - For users who can handle multiple logs and 1st oops is concerned. (by specifying panic_on_oops=1) > > Log_num=3,4 > - for users who care about 2nd or 3rd oops. > > Log_num=5 or more > Invalid value. What is the harm of not using this and just letting the number be infinite (or until EFI runs out of space)? Is it a big deal if extra failures are logged? The hope would be a daemon would clear the old logs out and you never run out of space. Cheers, Don -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
