Date: Mon, 11 Feb 2002 21:53:55 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: <freebsd-scsi@FreeBSD.ORG>, Frank Altpeter <frank@altpeter.de> Subject: Re: SCSI parity error detected Message-ID: <20020211213743.N1867-100000@gerard> In-Reply-To: <20020211235534.G57760@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Feb 2002, Joerg Wunsch wrote: > As G=E9rard Roudier wrote: > > > > Ah no. AFAICT, all that Sun's doing here is addings their "SUNxxG" t= o > > > the vendor string so their tools can quickly identify and categorize > > > their disks. > > > > Very probably. But it just makes their firmware suspicious. > > What a questionnable value-added. > > Well, from your point of view it might be questionable. From their > point of view (in particular from format(1m)'s point of view) it has > some value, since regardless of which vendor their "SUN9G" drive is > from, they use all those drives with the same settings, so they are > interchangeable in the field. They might lose a few sectors for some > drive, depending on the actual model used, but that doesn't hurt much. If your explanation is true, then this looks to me not only questionnable, but highly stupid. :-) > > I donnot know all hard disks in existence. Is this one wide capable? > > Yep, all the Sun SCA disks are wide-capable. > > > But the driver cannot guess it. And it doesn't understand the > > Dawicontrol settings from NVRAM (if some exists). > > Don't know about the NVRAM in Dawicontrol. According to Frank, it at > least doesn't have much BIOS knobs. If there is NVRAM, it should > never attempt to negotiate wide, since the entire controller is narrow > only. Dawicontrol uses proprietary BIOS and setup area not supported by the driver. Their BIOS very probably knows that the upper lines of the 53c875 that is _wide_ are not connected to the SCSI BUS. But the sym driver does not detect this. This could be achieved, for example, by providing a specific sub-vendor id. But for now, I donnot know if their controller provides such information. As a result, the sym driver does consider your 53c875 as wide-capable and will negotiate Wide for devices that say they support wide in their INQUIRY response. (In fact, it is CAM that tells the driver to negotiate Wide for device that report Wide capability, providing that the driver reported such a user setting for the device) > > Note that when the driver negotiates Wide, it negotiates also Sync > > immediately without any DATA phase occurring and reports the new > > parameters to CAM. As a result, the new transfer settings should be > > printed to the syslog prior to any further DATA phase. > > I think Frank posted all relevant messages in his initial mail. > > > OTOH, if there is no such message in the log, it could well be the > > initial INQUIRY response that got a SCSI PARITY error. The problem > > might then be the/a SCSI PARITY signal not being properly > > driven/connected. > > Hmm, but it used to be connected with the AHA1542. The AHA1542 will never negotiate Wide for the simple reason it is only Narrow-capable. In order to check the possible Wide nego. issue, the driver source can be hacked, for example, as follows: --- sym_conf.h.orig=09Sun Dec 2 16:21:07 2001 +++ sym_conf.h=09Mon Feb 11 21:49:46 2002 @@ -146,7 +146,7 @@ /* * Max wide order. */ -#define SYM_SETUP_MAX_WIDE=09(1) +#define SYM_SETUP_MAX_WIDE=09(0) /* * Max SCSI offset. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020211213743.N1867-100000>