From owner-freebsd-hackers Mon Jul 8 01:27:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA16484 for hackers-outgoing; Mon, 8 Jul 1996 01:27:21 -0700 (PDT) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA16472 for ; Mon, 8 Jul 1996 01:27:06 -0700 (PDT) Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id KAA00142 for ; Mon, 8 Jul 1996 10:26:52 +0200 (METDST) Received: from angrand.prism.uvsq.fr (angrand.prism.uvsq.fr [193.51.25.85]) by guillotin.prism.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id KAA00902 for ; Mon, 8 Jul 1996 10:26:51 +0200 (MET DST) Received: from (son@localhost) by angrand.prism.uvsq.fr (8.7.5/jtpda-5.2) id LAA05179 ; Mon, 8 Jul 1996 11:29:26 +0200 (MET DST) Date: Mon, 8 Jul 1996 11:29:26 +0200 (MET DST) Message-Id: <199607080929.LAA05179@angrand.prism.uvsq.fr> From: Nicolas Souchu To: hackers@freebsd.org Subject: polling driver Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk My ZIP driver freezes the system because it polls scsi requests (the drive is connected to the // port). There is no way to make the drive generate interrupts. Then I though about something like software interrupts, timeouts or tsleep()... Not a good idea. Processes which request the drive simultaneously enter in deadlock. One waits on channel "getblk" the other on "msdhgt". Surely, doing a tsleep() in a driver is a bad idea... I think resources are not well locked before the drive-dependent scsi_cmd() routine is called because the process is supposed to keep the CPU during the call and return without being interrupted. Timeouts are not good either because they interrupt the CPU at a high level (>splbio) and the callback is executed at a very low level. Please, tell me if I'm wrong. If I could find the reason of the deadlock, I could try to fix the problem... Any idea would be very appreciated. nicolas -- Nicolas.Souchu@prism.uvsq.fr Laboratoire PRiSM - Versailles, FRANCE