Hello, I wrote:
>>I'm not sure this is the correct solution, but I'd like to throw this
>>out in order to illustrate a couple of cases where KGDB could deadlock
>>when debugging under SMP. I've seen this in i386 and x86_64 versions.
>>It so happens that when you go into the INT3 handler, the IPI_NMI we
>>send to the slave processors may arrive when one of those processors
>>holds the runqueue (struct rq) lock. This could cause a deadlock. I've
>>seen it happen in two places:
>>1) While looping inside the kgdb_handle_exception(), your net polling
>>Ethernet driver (mine is e1000) tries to free SKB's using
>>dev_kfree_sdb_any(). If you don't bump your preempt to HARDIRQ, the
>>function would eventually deadlock trying to get the rq lock
>>(specifically in try_to_wake_up()).
BTW, that would also help us to get rid of the infamous/broken
CONFIG_NETPOLL_TRAP option by preventing wakeup_softirqd() from being called...
>>Tim Nguyen
WBR, Sergei
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
