Subject: Re: Axil HWS310
To: Kerberus <kerberus@microbsd.net>
From: Don Yuniskis <auryn@gci-net.com>
List: port-sparc
Date: 11/26/2001 14:43:43
>kerberus yelped:

>Well this is a seagate 2.5 Gig disk, are you saying i should try a
>different disk ???

Ah, well... that's always a nice first order of business -- but
not always possible!  :>

Note that I am just tossing out a suggestion based on the
*implication* in your previous comments that the Fast SCSI
characteristic was causing the problem (or, that you were
suspicious enough of it to think that it *might*!)

>And what would be required to edit the mode pages to
>disable synchronous mode, at this point ill try anything out! experience
>through learning is always considered knowledge.


I don't know if NBSD has a utility to edit mode pages
directly (sorry, too "new" to this).  And, it would also
pose the bootstrap/chicken-egg problem -- getting the
system *up* in order to talk to the drive... given that the
drive's presence seems to raise hell!

Note that esp(4) -- I assume that's the driver you that is
handling your disk? -- allows you to specify which SCSI ID's
are NOT asked to negotiate synchronous transfers in the
"flag" keyword.

True to form, the man page fails to document exactly *which*
bit is associated with each SCSI ID (one might assume that
0x1 controls ID 0, 0x80 controls ID 7, etc.).  Rather than
playing guessing games, I would suggest setting that byte
of "flags" to 0xFF (i.e. disable sync negotiation on *all*
devices) as it shouldn't have any deleterious effects
(besides slowing things down a bit).

*If* that makes a difference, you could then experiment
further to isolate the required flag bit.

HTH,  It would be worth commenting if it *does* so others
can avail themselves of this as a workaround.

--don

>On Mon, 2001-11-26 at 13:24, Don Yuniskis wrote:
>> >|> bwtwo at sbus0 slot2 offset 0x0 level 9:sunw,501-1561, 1152x900
console
>> >|>
>> >|> it goes baserk!
>> >
>> >I had a Sparc-10 panic at that point when I tried to use a Quantum
>> >Fireball TM hard drive. The 10's Fast SCSI controller, NetBSD's
>> >driver, and the notoriously bad SCSI implementation of that disk
>> >just didn't go together. That same disk works fine in a Sparc-2.
>>
>> Was this a result of the Fireball failing to negotiate synchronous
>> mode correctly?  I.e. could you have editted the mode pages to
>> disable synchronous negotiation and "limped along"?
>
>