Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds

[Alexander Motin]

On 30.07.2014 23:42, Joerg Wunsch wrote:
> freebsd-scsi at uriah.heep.sax.de (Joerg Wunsch) wrote:
> 
>> I think, somehow, SA_CCB_WAITING needs to be reintroduced into
>> sastart(), but the differences to the code in FreeBSD 8.x are
>> too many for me to decide *where*.  Perhaps it is the piece
>>
>>                 if (periph->immediate_priority <= periph->pinfo.priority) {
>>                         CAM_DEBUG_PRINT(CAM_DEBUG_SUBTRACE,
>>                                         ("queuing for immediate ccb\n"));
>>                         Set_CCB_Type(start_ccb, SA_CCB_WAITING);
>>                         SLIST_INSERT_HEAD(&periph->ccb_list, &start_ccb->ccb_h,
>>                                           periph_links.sle);
>>                         periph->immediate_priority = CAM_PRIORITY_NONE;
>>                         wakeup(&periph->ccb_list);
>>                 } else if (bp == NULL) {
>>
>> that needs to be placed before the current check for bp == NULL?
> 
> The respective change that broke it (on HEAD) was r256843.  I'm Cc'ing
> Alexander Motin (mav@) who committed that change.

Yes, that was me who removed that second type handling from sastart().
The same was done for all other drivers as part of CAM simplification
efforts. Probably I missed the fact that sa(4) uses that type for
something else. So while type may indeed be restored (I have no idea
about that aspect of sa(4) driver, neither have hardware to test it), it
should probably be set in some other point, since calls of type
previously called SA_CCB_WAITING are no longer going through that path
in sastart(). If needed, it may possibly be set after
cam_periph_getccb() calls, or may be made the default and set it only
for IO case in single place.

-- 
Alexander Motin