Date: Mon, 14 Dec 1998 01:52:36 +0000 From: Doug Ledford <dledford@redhat.com> To: Vincent Cojot <coyote@step.polymtl.ca> Cc: aic7xxx@FreeBSD.ORG Subject: Re: 5.1.6 failure too.. Message-ID: <36746F64.DE24F6D7@redhat.com> References: <Pine.GSO.4.03.9812132020300.23447-100000@step.polymtl.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Vincent Cojot wrote:
>
> Hello to everyone and to Doug,
>
> Looks like 5.1.6 isn't ok for me either:
>
> scsi: aborting command due to timeout: pid 46, scsi0, channel 0, id 5,
> lun0 Inquiry 00 00 00 ff 00
> (scsi0:0:5:0) Aborting scb 14, flags 0x4
> (scsi0:0:5:0) SCB found on hardware waiting list and aborted.
> (scsi0:0:5:0) Aborting scb 14
> (scsi0:-1:-1:-1) 1 commands found and queued for completion
>
> This scrolls on my console when I try to boot. scsi0:0:5:0 is my Tape
> Drive (HP SureStore dat8i).
>
> So far here are my results:
> 2.0.35 + aic7xxx-5.1.0-pre10 = OK
> 2.0.35 + aic7xxx-5.1.2 = Not OK
> 2.0.36 + aic7xxx-5.1.x (default, 5.1.5 I think) = Not OK
> 2.0.36 + aic7xxx-5.1.6 = Not OK
>
> Some people were saying that pre-14 was the last patch that was OK. Maybe
> I will try to downgrade 2.0.36 to that version and see what happens.. Do
> you have any idea what's going on, Doug? Thanks for reading...
Yes, I have an idea. Try the no_reset option to the driver. If that
solves your problem, then one of two things is true. Either the bus
reset at driver init time isn't happening properly (even if the driver
thinks it is, which is one problem I had before) or the device doesn't
like the bus reset (which isn't a problem I've seen with HP DATs in the
past so I doubt it).
The fix to your problem may be as simple as going into the
aic7xxx_detect() code around line 9066 and right after the call to
aic7xxx_chip_reset() adding an mdelay(250) or some such wait period. My
untested theory is that certain aic7xxx chips need a delay after the
chip reset before they will actually output anything on the SCSI bus
pins (more than just what running through the rest of the code provides
anyway). This is especially true with 7890 chips, and you can see that
the aic7xxx_register() function already has a delay in it specifically
for all ultra2 chipsets, but we may need a general delay to catch all of
the chipsets that need it. The other half of my theory is that freebsd
doesn't see this as readily because the freebsd code has separate
probe/attach calls where as in linux we attach the device and do the
full init sequence the moment we probe the PCI bus. I could be wrong on
that one though, Justin would have to comment there.
Another possibility is that in the aic7xxx_reset_current_bus() code your
particular card needs the reset pin to be pulled for a longer period of
time before things react. You could also have a bad reset pin on your
cable (don't scoff, I had someone recently let me know that their
endless reset loop problems was solved when they found that the
manufacturer of their external drive cabinet had intentionally cut the
reset pin in the cable so that no bus resets ever made it through, once
he replaced that cable things magically started working).
In any case, your description is entirely consistent with what happens
when the driver thinks that we have reset the bus (and set all devices
to narrow/async transfers) while the bus itself was never reset and the
devices are therefore still trying to use sync transfer rates. Things
simply die in the transfer phase.
--
Doug Ledford <dledford@redhat.com>
Opinions expressed are my own, but
they should be everybody's.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36746F64.DE24F6D7>