rrs added a comment. Hans:
Let me explain to you how I think you are wrong, you are missing a small subtle thing here.... When we do the callout_stop we set cc_migration_cpu() = CPUBLOCK *NOT* c->c_cpu = CPUBLOCK; You are confusing the two things. The CPUBLOCK is used in two different places. The loop in callout_lock() is looking for c->c_cpu != CPUBLOCK This only gets set when callout_cpu_switch() is called *not* when callout_reset or callout_stop is called. So I think you have the wrong fish in the net. What Hiren is seeing is something completely different. What is strange is the cc_cpu[] structures he dumped has *no* locks present.. Look back above and see the cc_lock structures of the cc_cpu's.. all of the owners are 4.. i.e. MTX_UNLOCKED. So how in the world are we getting a "thread holds spin lock too long". Worse the callout that was being "inserted" is ACTIVE and PENDING, which means it should be on the wheel, but it is *not* on the wheel .. at least not that I can see... since Hiren has traced back on that callout and the previous one on the list (which points to it) has a c_flags of 0.. This is very very odd. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
