From owner-aic7xxx Sun Dec 13 17:53:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11038 for aic7xxx-outgoing; Sun, 13 Dec 1998 17:53:37 -0800 (PST) (envelope-from owner-aic7xxx@FreeBSD.ORG) Received: from intrex.net (ns2.intrex.net [209.42.192.252]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA11033 for ; Sun, 13 Dec 1998 17:53:36 -0800 (PST) (envelope-from dledford@redhat.com) Received: from redhat.com [209.42.199.181] by intrex.net with ESMTP (SMTPD32-4.07) id A0533FD023C; Sun, 13 Dec 1998 20:56:35 EST Message-ID: <36746F64.DE24F6D7@redhat.com> Date: Mon, 14 Dec 1998 01:52:36 +0000 From: Doug Ledford Organization: Red Hat Software X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.36 i686) X-Accept-Language: en MIME-Version: 1.0 To: Vincent Cojot CC: aic7xxx@FreeBSD.ORG Subject: Re: 5.1.6 failure too.. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 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