rrs added a comment.
Hans:
I think your wrong here. The caller of callout_cpu_switch() is holding
the CC_LOCK(). Now there are only two callers of this function.
Either the actual callout code itself (softclock_call_cc()) or
the callout_reset_sbt_on(). In the case of callout_reset_sbt_on().
So lets look at these two cases
Case 1: soft clock_call_cc() - In this case the callout is finished
and is being migrated to a different CPU. This would have
happened only because we had the case of doing a
callout_reset_sbt_on() and finding the callout executing
on the wheel *is* the callout running now and we can't
do the migration, so the CPU is set and the
PENDING/MIGRATION/ACTVIE
flags are also present. The callout lock is held from the
perspective
of the original CPU, and the code goes through and releases the
lock only after setting in the c_lock = CPUBLOCK which will
prevent any
other running callout_reset_sbt_on() from moving forward, they will
be stuck waiting for the c_lock to clear to a CPU number. When the
migration
is complete the function restores the cpu and the other guy can
proceed. It
may be moving to yet another CPU, that would be fine too since it
now has
the lock on the new CPU and moves forward out of
callout_reset_sbt_on()
2) callout_reset_sbt_on() - here again we have the current CPU callout lock,
and
we will only do the switch if the callout is not the current guy executing,
if it
is we set the flags so <1> above occurs. If its not we move it.. again we
set the CPUBLOCK on the callout so no there callout_reset_sbt_on() can get
in until after we move it.
So there is no way we can have two guys moving at the same time. The CPUBLOCK on
the c->c_cpu is used to serialize the two guys.
This of course is all noise, since it is *not* related in any shape or form to
what
Hiren is seeing. If it was you would have seen the panic not at line 530 but
above that..
So the question is what is happening.. I am still contemplating it.. and
hopefully I can
figure out a way to recreate it.. without a vmcore/kernel.debug its pretty hard
to
decipher these things.. Hiren has been a wonderful help but I am afraid I am
about
out of question to ask for now.. Its very very strange.
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"
