cvs commit: src/sys/dev/twa tw_osl_cam.c

[Scott Long]

Vinod Kashyap wrote:
> 
>>-----Original Message-----
>>From: owner-src-committers at FreeBSD.org
>>[mailto:owner-src-committers at FreeBSD.org]On Behalf Of Scott Long
>>Sent: Friday, April 29, 2005 2:24 PM
>>To: Vinod Kashyap
>>Cc: Bjoern A. Zeeb; src-committers at FreeBSD.org; cvs-src at FreeBSD.org;
>>cvs-all at FreeBSD.org
>>Subject: Re: cvs commit: src/sys/dev/twa tw_osl_cam.c
>>
>>
>>Vinod Kashyap wrote:
>>
>>>>-----Original Message-----
>>>>From: owner-src-committers at FreeBSD.org
>>>>[mailto:owner-src-committers at FreeBSD.org]On Behalf Of Bjoern A. Zeeb
>>>>Sent: Friday, April 29, 2005 1:29 PM
>>>>To: Vinod Kashyap
>>>>Cc: src-committers at FreeBSD.org; cvs-src at FreeBSD.org; 
>>>>cvs-all at FreeBSD.org
>>>>Subject: Re: cvs commit: src/sys/dev/twa tw_osl_cam.c
>>>>
>>>>
>>>>On Fri, 29 Apr 2005, Vinod Kashyap wrote:
>>>>
>>>>
>>>>
>>>>>vkashyap    2005-04-29 20:03:20 UTC
>>>>>
>>>>> FreeBSD src repository
>>>>>
>>>>> Modified files:
>>>>>   sys/dev/twa          tw_osl_cam.c
>>>>> Log:
>>>>> Make call to tw_cl_deferred_interrupt in twa_poll, not 
>>>>
>>>>dependent on the
>>>>
>>>>
>>>>> return value from tw_cl_interrupt.
>>>>>
>>>>> Revision  Changes    Path
>>>>> 1.2       +12 -2     src/sys/dev/twa/tw_osl_cam.c
>>>>
>>>>With this I can reboot the machine again. Thanks.
>>>>
>>>
>>>
>>>I still believe that CAM should not be calling the polling function
>>>when interrupts are active, but in the absence of an answer to why
>>>that is so, this can be a work-around.
>>>
>>>
>>
>>CAM calls the poll routine when it's not sure if interrupts are
>>enabled and it wants to make sure that SIM will complete all
>>outstanding commands.  It's the same way that every other CAM
> 
> 
> In that case, it's probably a good idea to define SIM entry points
> that CAM can call to enable/disable interrupts on the controller.
> By doing this, CAM can first disable interrupts, and then go ahead
> and poll.
> 

Why exactly does CAM need to go in and mess with the hardware behind
the back of the driver?  If you really need to disable interrupts
that badly, just do it from the poll routine.  But, that's not the
problem here.  The problem is that you have races in between setting
and checking state, and you assume that the scheduler will always be
running and allow the taskqueue to run.

Scott