on 23/01/2012 15:07 Gleb Smirnoff said the following: > On Mon, Jan 23, 2012 at 10:21:57AM +0200, Andriy Gapon wrote: > A> > I can confirm that I can reboot succesfully with a new kernel > A> > and kern.stop_scheduler_on_panic=0. > A> > A> This is very puzzling. You observation means that stop_scheduler_on_panic has > A> an effect on the code outside the panic path. I reviewed the > A> SCHEDULER_STOPPED() changes and I still can not see how that could be possible > A> (modulo compiler bugs). > A> > A> Unfortunately, I also can not reproduce the problem here - without > A> WITNESS_SKIPSPIN I am running into a panic[*] during boot. > > I suppose your patch (the one in other post) should help against > this panic on boot. Yes, it does. It also masks/fixes the panic at reboot. > A> BTW, do you get any other LOR reports _before_ you do a reboot? > > I have some, but I don't think they are related. OK. > A> Can you try to change printfs in witness to db_printfs? Perhaps this will allow > A> to get the details of the LOR in uart_cnputc. Maybe that will reveal some > A> important additional details. > > Should I do s/printf/db_printf/ throughout entire subr_witness.c, or only > in special places? I think that "replace all" should work for this test. > A> Finally, can you try the patch from my other post? > > Yes, it works. > Thank you again. -- Andriy GaponReceived on Mon Jan 23 2012 - 13:01:23 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:23 UTC