On Sat, Jun 29, 2019 at 08:23:51AM -0700, Doug Anderson wrote: > Hi, > > On Fri, Jun 28, 2019 at 8:17 PM Jason Wessel <jason.wes...@windriver.com> > wrote: > > > > On 6/28/19 4:17 PM, Doug Anderson wrote: > > > I was trying to debug a crash using kdb / kgdb today and ran into a > > > problem I've seen before: being unable to get kdb / kgdb to debug one > > > of important tasks on the system. Specifically I was unable to use > > > kdb to point to the CPU running the task and there was no shadow CPU > > > in kgdb. Running "ps" in kdb showed: > > > > > > 0xecc9bd80 111 2 1 0 R 0xecc9c488 kworker/0:1H > > > Error: no saved data for this cpu > > > > > > I decided to dig a little bit more this time and found that the > > > problem appears to be that "panic" stops all CPUs before calling the > > > panic notifier and then kdb / kgdb shows the CPU as dead. > > > > > > I wondered if anyone has given any thought to this problem before. > > > Obviously a "fix" is to add a special case for kdb / kgdb in the > > > panic() function before the CPUs die, but presumably that will be met > > > with resistance. I'm curious if anyone else has good ideas. > > > > > > > > > -Doug > > > > > > You could set a breakpoint at panic(), instead of waiting for the notifier. > > Yup, I've got that as a workaround. I was wondering more about if > anyone had brilliant ideas about a solution that might be able to land > upstream. I guess maybe the best bet is to just try sending up a > patch to add a special case to panic() and see what falls out. ;-)
Probably, yes. There's not a lot of love for notifiers these days so there would be some grounds for optimism here! Daniel. _______________________________________________ Kgdb-bugreport mailing list Kgdb-bugreport@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
