Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 31 Jul 2014 00:10:57 +0300
From:      Alexander Motin <mav@FreeBSD.org>
To:        Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>,  freebsd-scsi@freebsd.org
Cc:        ken@freebsd.org
Subject:   Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds
Message-ID:  <53D95F61.4080701@FreeBSD.org>
In-Reply-To: <20140730204200.4645729B8@uriah.heep.sax.de>
References:  <20140729090724.GA26577@uriah.heep.sax.de> <201407291823.s6TINAad032318@higson.cam.lispworks.com> <20140729191829.GK3121@uriah.heep.sax.de> <20140729204354.GA78616@nargothrond.kdm.org> <20140729224414.E2AAE276@uriah.heep.sax.de> <20140730035230.GA81800@nargothrond.kdm.org> <20140730060330.GA3272@uriah.heep.sax.de> <20140730153229.GA86368@nargothrond.kdm.org> <20140730191915.9B944267B@uriah.heep.sax.de> <20140730203315.0EED1295B@uriah.heep.sax.de> <20140730204200.4645729B8@uriah.heep.sax.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On 30.07.2014 23:42, Joerg Wunsch wrote:
> freebsd-scsi@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53D95F61.4080701>