[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Results of trying 2.6.7 and 2.6.8 on Macintosh Quadra 650



On Thu, 2004-08-26 at 15:52, Finn Thain wrote:
> /dev/scsi/host0/bus0/target0/lun0:esp0: Aborting command
> esp0: dumping state
> esp0: SW [sreg<07> sstep<04> ireg<0c>]
> esp0: HW reread [sreg<01> sstep<c4> ireg<10>]
> esp0: current command [tgt<00> lun<00> pphase<FREEING> cphase<CLUELESS>]

Hmm, this definately looks like a reselection issue. The last state the
driver saw was "Reselected, current bus phase is MSG IN". After which it
reconnects the command (which seems to have gone fine) and sets the
command phase to <CLUELESS>, and then waits for the next interrupt.

But that doesn't seem to come, at the time of command abort the HW is
reread and we find out it's showing "Bus service, current bus phase is
DATA IN".

I've looked at the diffs in the Mac CVS repository. They mostly seem to
involve adding a disconnect mask to keep track of disconnected devices
so no new commands are sent to these devices. Except I don't think
that's needed if the driver registers with cmd_per_lun=1, which all
NCR53C9x users seem to do. As far as I know this prevents the mid level
layer to throw any other command for the same target/lun at the LLD when
another command is still active.

I would have expected more problems if this really was needed, I never
have any problems with the driver on my hardware. And yes, my SCSI
devices do disconnect/reselect.

Which leaves as only relevant change the possibility to globally disable
disconnects, but I don't really like that.

The Mac seems to be the only platform with these issues, I expect the
problem to be somewhere in the PIO transfer routine (as far as I know
only the Mac driver uses it, all other drivers use some form of DMA).

I'd like someone to try a kernel with the following patch, it makes the
Mac 'goto' slightly more intelligent, it should now 'remember' devices
which bugger up when disconnecting.

If this doesn't work, perhaps enable the debug macros in NCR53C9x.h and
see if we can figure it out from the logs.

Index: drivers/scsi/NCR53C9x.c
===================================================================
RCS file: /home/linux-m68k/cvsroot/linux/drivers/scsi/NCR53C9x.c,v
retrieving revision 1.1.1.23
diff -u -r1.1.1.23 NCR53C9x.c
--- drivers/scsi/NCR53C9x.c	15 Aug 2004 14:17:09 -0000	1.1.1.23
+++ drivers/scsi/NCR53C9x.c	1 Sep 2004 20:47:47 -0000
@@ -1109,12 +1109,15 @@
 		 * Macintosh. Well, maybe later when we figured out how to 
 		 * do DMA on the machines that support it ...
 		 */
-		esp_dev->disconnect = 1;
-		esp_dev->sync_max_offset = 0;
-		esp_dev->sync_min_period = 0;
-		esp_dev->sync = 1;
-		esp->snip = 0;
-		goto do_sync_known;
+		if(MACH_IS_MAC) {
+			if(!SDptr->borken)
+				esp_dev->disconnect = 1;
+			esp_dev->sync_max_offset = 0;
+			esp_dev->sync_min_period = 0;
+			esp_dev->sync = 1;
+			esp->snip = 0;
+			goto do_sync_known;
+		}
 #endif
 		/* We've talked to this guy before,
 		 * but never negotiated.  Let's try




Reply to: