Subject: Re: Patch for recent ncr.c lossage / not just ncr.c
To: Erik Bertelsen <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 10/16/1999 11:18:27
On Sat, 16 Oct 1999 11:08:10 +0200
Erik Bertelsen <firstname.lastname@example.org> wrote:
> Sigh :-(
Yah, I know.
Do me a favor, and set the "ncr53c9x_debug" variable in ncr53c9x.c so that
you can get a trace of that driver's activity? The mid-layer, according
to your bug report, appears to be waiting for the chip driver to finish
processing the command.
> One of the cvs log entries for ncr.c (by cgd?) mentioned something about
> walking around a problem with Quantum disks -- could that be relevant?
That problem is not related to yours at all. In his case, the (horribly
broken) Quantum disk he was using was interpreting the tag value of the
Queue Tag that the NCR driver was handing it, returing QUEUE FULL status.
Due to the way NCR assigns tags, it could never recover from this condition.
Also, the NCR script was pooched in its handling of QUEUE FULL status.
Since the 53c9x core does not do tagged queueing, you can't suffer from this
-- Jason R. Thorpe <email@example.com>