Date: Fri, 29 Apr 2005 17:25:21 -0700 From: "Vinod Kashyap" <vkashyap@amcc.com> To: Scott Long <scottl@samsco.org> Cc: cvs-src@FreeBSD.org Subject: RE: cvs commit: src/sys/dev/twa tw_osl_cam.c Message-ID: <IFQH6T04.06T@hadar.amcc.com>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-src-committers@FreeBSD.org > [mailto:owner-src-committers@FreeBSD.org]On Behalf Of Scott Long > Sent: Friday, April 29, 2005 2:57 PM > To: Vinod Kashyap > Cc: Bjoern A. Zeeb; src-committers@FreeBSD.org; cvs-src@FreeBSD.org; > cvs-all@FreeBSD.org > Subject: Re: cvs commit: src/sys/dev/twa tw_osl_cam.c > = > = > Vinod Kashyap wrote: > > = > >>-----Original Message----- > >>From: owner-src-committers@FreeBSD.org > >>[mailto:owner-src-committers@FreeBSD.org]On Behalf Of Scott Long > >>Sent: Friday, April 29, 2005 2:24 PM > >>To: Vinod Kashyap > >>Cc: Bjoern A. Zeeb; src-committers@FreeBSD.org; cvs-src@FreeBSD.org; > >>cvs-all@FreeBSD.org > >>Subject: Re: cvs commit: src/sys/dev/twa tw_osl_cam.c > >> > >> > >>Vinod Kashyap wrote: > >> > >>>>-----Original Message----- > >>>>From: owner-src-committers@FreeBSD.org > >>>>[mailto:owner-src-committers@FreeBSD.org]On Behalf Of = > Bjoern A. Zeeb > >>>>Sent: Friday, April 29, 2005 1:29 PM > >>>>To: Vinod Kashyap > >>>>Cc: src-committers@FreeBSD.org; cvs-src@FreeBSD.org; = > >>>>cvs-all@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 rou= tine. I just don't expect the poll routine to be called when interrupts are activ= e. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?IFQH6T04.06T>