Subject: Re: vmunix.644

From: [email-masked] (Markus Wild)

> Sync mode worked for me with 613 but stopped working when I moved up to
> 644. I got tired of having it work for a couple of releases and then not
> working for a few more, so I went to the root of the problem. I finally
> got around to replacing my early 04-PROTO SCSI chip with a new one. Now
> sync mode on my MXT540SL works great.

Interesting.. 

In the hope of someone having an idea of what might be going on here, I'll
try to summarize what changed recently in the scsi area. 

First, some background (from my a3000 perspective, things might be slightly
different on other hardware combos):
- When the machine is rebooted or switched on, the ROM scsi.device gets
  initialized.
- Any drives (mostly SCSI-2) that are configured to initiate sync handshake
  will do that after spinup. scsi.device will negotiate with them a common
  set of sync parameters.
- If the "initiate sync" bit in battmem is set, scsi.device will instead
  initiate sync handshake with drives.
* as a resume: we now have drives operating in sync mode if either they have
  been asking for it themselves, or scsi.device asked them for it if 
  "initiate sync" was true, and their "Inquiry" page said they're capable
  of going sync.
- on start of NetBSD, its scsi driver faces the problem that it can't know
  which drives have been set to sync mode, and if yes, with what parameters.
- the correct thing to do now would be to pull the SCSI bus RESET line, 
  however, the A3000 scsi interface doesn't allow access to that line except
  by resetting the machine.
- the solution used by older kernels was to send a BUS_DEVICE_RESET scsi
  command to all targets. The big drawback of this method was that some older
  drives completely locked up upon receiving this command. A minor drawback
  was that resetting drives may take a considerable time, so booting BSD was
  sloooow.
- the new kernels use a different strategy. They actively perform a sync-
  handshake upon first selecting a target. To make sure no data phases (with
  unknown sync status) can interfere before this handshake, the sync handshake
  is performed on the very first mesg-out, right after the IDENT mesg.
# my wild guess: some drives don't like receiving the sync message at that
  time.

So.. any ideas about point #? If I do the handshake later, I (as initiator)
have to request another MsgOut phase, but since the target is totally free
of when to grant that request, it may proceed to data-in/out before, and then
it would lock up, if it's set to sync already.

The reason why the old PROTO chip *might* lock up with this approach *could*
lie in weird state changes of scsi bus lines. I've heard the proto chip had
some problems when a target dropped one line (don't remember which) too early,
corrupting its internal transfer-count register.

Comments are welcome!

-Markus
-- 
CHUUG/EUnet Switzerland				Markus Wild
Zweierstrasse 35	Tel: +41 1 291 45 80	[email-masked]
CH-8004 Zuerich		Fax: +41 1 291 46 42	S=mw;P=EUnet;A=EUnet;C=CH