More RedHat and Promise

[Todd Denniston]

"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 at 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
<SNIP>
[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