[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201702162318.52483.linux@rainbow-software.org>
Date: Thu, 16 Feb 2017 23:18:51 +0100
From: Ondrej Zary <linux@...nbow-software.org>
To: Finn Thain <fthain@...egraphics.com.au>
Cc: "James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Michael Schmitz <schmitzmic@...il.com>,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: g_NCR5380 PDMA, was Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches
On Tuesday 31 January 2017 02:31:45 Finn Thain wrote:
[...]
> Are you trying to figure out which commands are going to disconnect during
> a transfer? This is really a function of the firmware in the target; there
> are no good heuristics AFAICT, so the PDMA algorithm has to be robust.
> mac_scsi has to cope with this too.
>
> Does the problem go away when you assign no IRQ? When instance->irq ==
> NO_IRQ, the core driver will inhibit disconnect privileges.
Yes, it seems to run fine with IRQ/disconnect disabled.
With IRQ enabled, "dd if=/dev/sr0 of=anything" stops after a while. I get
gated 53C80 IRQ, BASR=0x10, MODE=0x0e, STATUS=0x7c.
When I enable interrupts during PDMA (like the removed UNSAFE macro did), the
problems go away. I see an IRQ after each pread call.
(had to disable "no 53C80 gated irq after transfer" and "no end dma signal"
messages to reduce log spam)
--
Ondrej Zary
Powered by blists - more mailing lists