From owner-aic7xxx@FreeBSD.ORG Fri Feb 13 16:33:25 2004 Return-Path: Delivered-To: aic7xxx@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CAA716A4CE for ; Fri, 13 Feb 2004 16:33:25 -0800 (PST) Received: from glock.ssa.crane.navy.mil (glock.ssa.crane.navy.mil [164.227.42.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2896943D1D for ; Fri, 13 Feb 2004 16:33:25 -0800 (PST) (envelope-from Todd.Denniston@ssa.crane.navy.mil) Received: from ssa.crane.navy.mil (tdennist@localhost [127.0.0.1]) by glock.ssa.crane.navy.mil (8.9.3/8.9.3) with ESMTP id TAA04710; Fri, 13 Feb 2004 19:32:39 -0500 Sender: tdennist@glock.ssa.crane.navy.mil Message-ID: <402D6CA7.8711D731@ssa.crane.navy.mil> Date: Fri, 13 Feb 2004 19:32:39 -0500 From: Todd Denniston Organization: Code 6067, NSWC Crane X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.25glock1 i686) X-Accept-Language: en MIME-Version: 1.0 To: "P. Larry Nelson" References: <4027CC1E.E513281@ssa.crane.navy.mil> <4027E33E.D0575293@uiuc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: aic7xxx@freebsd.org Subject: Re: More RedHat and Promise X-BeenThere: aic7xxx@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Adaptec Device Drivers in FreeBSD and Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2004 00:33:25 -0000 "P. Larry Nelson" wrote: > > I have not had any better luck. > > I emailed Promise tech support on January 29 and have not heard a peep > from them. Your email prompted me to rattle their cage again. I even > asked if they would at least acknowledge receipt of my email. We'll see. > I included a return receipt request for both their email server and email client. the server is slow, took almost an hour to acknowledge receipt. the clients are even slower I sent the message '09 Feb 2004 19:48:17' UTC and received the return receipt '13 Feb 2004 17:08:19' UTC, and still no person written email. however I decided to call 11 Feb. and got some feed back, mainly 'hey new firmware dated 2004/2/4, try it'. version 1.1.0.37 I have tried it now, results mixed. still getting card dump, but when the dump finishes instead of panicking the kernel it gives me some queuing abort messages[1], with command not found, and goes on with life. This more acceptable, but I will be looking into the messages and seeing if I can try the new drivers. On the new driver front, because rpm's give me fits I had to `rpm2tgz aic7xxx-6.3.5-rh90.i686.rpm` so I could see what it was installing, after reading the install section of the included readme.txt, it all becomes easier, there's even a nice section on how to set the tag queue depth. BTW gibbs@scsiguy, which kernel tree is that based off of, fedora's 2.4.22-1.2115.nptl or something else? For some reason I can't get the kernel tree shipped with fedora core1 to *compile* with the exact config file for the kernel they shipped and is running, which confuses me greatly. > I have not tried new drivers, primarily due to inexperience in this > area and time constraints as well as the fact that my boss has taken > the Promise and moved it to another system (HP Alpha/Tru64 Unix) where > it works flawlessly. > > I also have an open ticket with RedHat, also since Jan. 29. At least > I'm getting an ongoing dialoge with them, tho it's slow going. We've > paid for this kind of support, so even tho I suspect it's a Promise > issue, I thought I'd at least get RedHat looking into it as well. > After all, the Promises work error-free with Win2K (incidentally > on the same exact hardware that's now running RHEL-ES.3 and where > now the Promise hangs) and with HP's Alphas running their Tru64 Unix. > So, one thing I'm absolutely sure of it's NOT a harware issue. I wonder if its just that linux can hit it faster? Also I have found window's tries real hard to never let you see a device error. Try a zip disk with bad blocks in an internal ide zip drive, if you copy the directory structure which hits the blocks, after waiting ~1 minute it'll finally just say could not find file [at least that was my experience]. I found that to cause the errors consistently I had to get a `badblocks -w -c 10000` going on all 5 of the drives simultaneously [0.5]. > > If I get any useful feedback from either Promise or redHat, I'll post here. > > - Larry [0.5] put it in JBOD to check all drives for bad blocks because one already failed, and I wanted to make sure the rest of the brand new 200GB drives were ok. [1] Feb. 13 18:33:23 bar kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> Feb. 13 18:33:23 bar kernel: scsi0: Bus Device Reset on A:0. 0 SCBs aborted Feb. 13 18:33:23 bar kernel: scsi0:0:1:0: Attempting to queue an ABORT message Feb. 13 18:33:23 bar kernel: CDB: 0x28 0x0 0x0 0x0 0x6a 0x20 0x0 0x3 0x30 0x0 Feb. 13 18:33:23 bar kernel: scsi0:0:1:0: Command not found Feb. 13 18:33:23 bar kernel: aic7xxx_abort returns 0x2002 Feb. 13 18:33:23 bar kernel: scsi0:0:2:0: Attempting to queue an ABORT message Feb. 13 18:33:23 bar kernel: CDB: 0x28 0x0 0x0 0x0 0x47 0x30 0x0 0x0 0xd0 0x0 Feb. 13 18:33:23 bar kernel: scsi0:0:2:0: Command not found Feb. 13 18:33:23 bar kernel: aic7xxx_abort returns 0x2002 Feb. 13 18:33:23 bar kernel: scsi0:0:2:0: Attempting to queue an ABORT message Feb. 13 18:33:23 bar kernel: CDB: 0x28 0x0 0x0 0x0 0x44 0x0 0x0 0x3 0x30 0x0 Feb. 13 18:33:23 bar kernel: scsi0:0:2:0: Command not found Feb. 13 18:33:23 bar kernel: aic7xxx_abort returns 0x2002 Feb. 13 18:33:23 bar kernel: scsi0:0:3:0: Attempting to queue an ABORT message Feb. 13 18:33:23 bar kernel: CDB: 0x28 0x0 0x0 0x0 0x3c 0x0 0x0 0x3 0x30 0x0 Feb. 13 18:33:23 bar kernel: scsi0:0:3:0: Command not found Feb. 13 18:33:23 bar kernel: aic7xxx_abort returns 0x2002 Feb. 13 18:33:23 bar kernel: scsi0:0:3:0: Attempting to queue an ABORT message Feb. 13 18:33:23 bar kernel: CDB: 0x28 0x0 0x0 0x0 0x3f 0x30 0x0 0x0 0xd0 0x0 Feb. 13 18:33:23 bar kernel: scsi0:0:3:0: Command not found Feb. 13 18:33:23 bar kernel: aic7xxx_abort returns 0x2002 Feb. 13 18:33:23 bar kernel: scsi0:0:4:0: Attempting to queue an ABORT message Feb. 13 18:33:23 bar kernel: CDB: 0x2a 0x0 0x0 0x7 0x85 0xb0 0x0 0x0 0xd0 0x0 Feb. 13 18:33:23 bar kernel: scsi0:0:4:0: Command not found Feb. 13 18:33:23 bar kernel: aic7xxx_abort returns 0x2002 Feb. 13 18:33:23 bar kernel: scsi0:0:4:0: Attempting to queue an ABORT message Feb. 13 18:33:23 bar kernel: CDB: 0x2a 0x0 0x0 0x7 0x82 0x80 0x0 0x3 0x30 0x0 Feb. 13 18:33:23 bar kernel: scsi0:0:4:0: Command not found Feb. 13 18:33:23 bar kernel: aic7xxx_abort returns 0x2002 Feb. 13 18:33:23 bar kernel: scsi0:0:0:0: Attempting to queue a TARGET RESET message Feb. 13 18:33:23 bar kernel: CDB: 0x28 0x0 0x0 0x0 0xac 0x40 0x0 0x3 0x30 0x0 Feb. 13 18:33:23 bar kernel: scsi0:0:0:0: Command not found Feb. 13 18:33:23 bar kernel: aic7xxx_dev_reset returns 0x2002 -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter