From owner-cvs-all@FreeBSD.ORG Sat Apr 30 00:25:42 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75EDA16A4CE; Sat, 30 Apr 2005 00:25:42 +0000 (GMT) Received: from hadar.amcc.com (hadar.amcc.com [192.195.69.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1490143D41; Sat, 30 Apr 2005 00:25:42 +0000 (GMT) (envelope-from vkashyap@amcc.com) Received: from mailhost01.amcc.com ([192.195.69.30]) by hadar.amcc.com (Netscape Messaging Server 4.15) with SMTP id IFQH6T04.06T; Fri, 29 Apr 2005 17:25:41 -0700 Received: (from vkashyap-pc [10.66.13.13]) by mailhost01.amcc.com (SMSSMTP 4.0.0.59) with SMTP id M2005042917264518190 ; Fri, 29 Apr 2005 17:26:45 -0700 From: "Vinod Kashyap" To: Scott Long Date: Fri, 29 Apr 2005 17:25:21 -0700 X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4 51114 (9.0.6627) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: cc: "Bjoern A. Zeeb" cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org Subject: RE: cvs commit: src/sys/dev/twa tw_osl_cam.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2005 00:25:42 -0000 > -----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.