Adaptec 2842 VLB, aic7xxx and zip-drive

[Steve Brueggeman]

5.0.9 patch is still no-go for me either.  

Had time to do a little more experimenting, (very little).

It's appears that it's only when I set the BIOS for my tape to WIDE that the
boot fails.  If I set my Sync for 40MB (Tape negotiates to 5Mhz), but no WIDE,
it still boots, but have noticed a difference between aic7xxx-4.1.1 and
aic7xxx-5.0.x.  

The offset value reported at boot time for my tape was 15 with ver 4.1.1, but is
8 for ver 5.0.8.  I do not know what the Adaptec handels, and I still have not
gotten the SCSI trace to see what everybody's asking for here.  Just wondering
if the offset byte of the period/offset pair returned by the tape is getting
dropped off, or if it's an indication that I have a naughty tape, and it's
returning an offset of 15, even though it was asked to do 8.

Also, driver 4.1.1 states that the Tape is "Refusing WIDE negotiation; using 8
bit transfers".  I take this to mean that the tape is responding with reject, as
you stated.

Ah, the rub, one reject MSG for whole DISC/PERD/OFST/WIDTH negotiation sequence.
(?Right?) I should get a SCSI bus trace.  SCSI does have it's bad side.  Then
again, maybe not.

Then again it could mean nothing.

I have not tried driver versions 5.0.0 through 5.0.7 (yet?).

I should probably add that I have a pretty loaded SCSI bus, for operating at
Ultra-1 speeds (6 Ultra-Wide drives, AND 1 narrow tape, on about 2.5 feet of
cable, 3" between devices, using 2049UW to convert to Narrow bus for Tape).  I
appear to be able to operate at Ultra-1 speeds on all of my drives OK though,
and tape appears to operate well, so I have not considered this as a problem.
Just one of those random considerations that float through when things aren't
working.


Plenty willing to do experimentation at your command.

Thanks for looking into this!!!

Steve Brueggeman.


>Doug Ledford wrote:
>
>> testing.  So, I've attached a test patch to this email.  If it works for
>> people, this will become the new 5.0.9 driver.  The patch applies against an
>> already 5.0.8 kernel.  If this works, then I'll give a more complete
>> description of what the problem was since 5.0.8 technically should have been
>> more reliable in regards to the REQINIT handler than 5.0.7, but I think the
>> changes I made uncovered a second bug in the REQINIT system that Justin
>> might be interested in.
>
>I tested your patch. Well, it doesn't work but there were two new messages  at
>the very top of the screen :
>
>(scsi0:0:4:0) SCSISIGI 0x0 SEQADDR 0x1, SSTAT0 0x7, SSTAT1 0x0
>(scsi0:0:4:0) invalid SCB ID 29 is active, SCB flags=0x404
>
>the rest is similar to the output of the 5.0.8 driver
>
>Staying ready to test an other patch ...
>
>Michel
>
>
>
>To Unsubscribe: send mail to majordomo at FreeBSD.org
>with "unsubscribe aic7xxx" in the body of the message


To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message