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

[Vinod Kashyap]

> -----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:57 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 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

If I did it in the poll routine, I wouldn't know when to undo it if needed,
unlike in the case of the caller of the poll routine.

> 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.

No, I do not assume that taskqueue handlers can be run at all times.  In
fact, that's the reason I don't register taskqueue handlers in the poll routine.
I just don't expect the poll routine to be called when interrupts are active.

Whatever that is, I don't want to get into a prolonged discussion/argument
about this.  Now that a work-around is in place, I will just go with it.