Created attachment 203379 [details] SS kernel panic at CAM r345853
Created attachment 203380 [details] SS
The allocation itself is in ZFS, which may or may not be interesting.
And the value is 0x5e010600, which is the first 32 bits of an 8? byte allocation. We expected to find the value uma_junk, which unless otherwise, is 0xdeadc0de. The only bits that match 0xdeadc0de are 0x5e010000; i.e., we've cleared bits 0x80acc0de and set bit 0x600.
M_CAMPERIPH is only associated with a few possible short (8 byte) allocations. I guess it's also possible that some previous owner is the one using it after free, not CAM.
Still, r345656 is in this area and was quite recent. It is consistent with OP's reported revision where the fault was observed. CC'ing mav.
(In reply to Conrad Meyer from comment #5) In r345874 the failure disappeared.
Michail, revision r345874 is from stable/12 branch. Are you sure it is right? I'd be happy if problem gone, but I see nothing obviously relevant between r345853 and r345874. Also, what user-space tools using CAM interface are you using? How can I reproduce the issue?
(In reply to Alexander Motin from comment #7) Nothing special, it failed at r345853 when two disk subsystem over-loading tasks were run: `portmaster -a` and `make -j8 buildworld` at the same time. It turned out to be actual and simple real burning test, by the way. After `svn up` to the latest src (at that time it turned out to be r345874) and kernel recompile the failure never appeared again. As I recall through my personal experience, there were few such kernel panic failures from 9 to Current/13 FreeBSD version. Thank you for support & development.