Date: Mon, 09 Feb 2004 13:45:02 -0600 From: "P. Larry Nelson" <lnelson@uiuc.edu> To: Todd Denniston <Todd.Denniston@ssa.crane.navy.mil> Cc: aic7xxx@freebsd.org Subject: Re: More RedHat and Promise Message-ID: <4027E33E.D0575293@uiuc.edu> References: <4027CC1E.E513281@ssa.crane.navy.mil>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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. If I get any useful feedback from either Promise or redHat, I'll post here. - Larry Todd Denniston wrote: > > Hi Larry & list, > I was wondering if you had any (better) luck with Mr. Gibbs new drivers in the > 6.3.X series[1], or if you had gotten anywhere with Promise? > > The reason I ask is I have two systems[2] similar to yours with VERY similar > errors to what you had[3] [4]. > > [1] Wed Dec 17 22:21:42 PST 2003 > http://lists.freebsd.org/pipermail/aic7xxx/2003-December/004052.html > [2]both identical > -Fedora Core release 1 (Yarrow) > -Linux-2.4.22-1.2115.nptl > -Promise UltraTrack RM8000 [firmware 1.1.0.17 on both] > -Adaptec AHA-3960D / AIC-7899A U160/m > -drbd-0.6.10 [mirroring partitions on the Promise drive between the systems] > - The systems were left idle for ~64 hours (there were > some services running but no one was accessing them) , > and then one of the systems had the errors below[4] and > when it was passed to drbd, the system kernel panicked (as drbd is configured > to do when the lower layer fails). > > [3] Wed Dec 17 14:58:39 PST 2003 > http://lists.freebsd.org/pipermail/aic7xxx/2003-December/004051.html > > [4] > Feb 9 04:04:28 bar kernel: scsi0:0:0:0: Attempting to queue an ABORT message > Feb 9 04:04:28 bar kernel: CDB: 0x2a 0x0 0x0 0x0 0x0 0x5f 0x0 0x0 0x8 0x0 > Feb 9 04:04:28 bar kernel: scsi0: At time of recovery, card was not paused > Feb 9 04:04:28 bar kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins > <<<<<<<<<<<<<<<<< > Feb 9 04:04:28 bar kernel: scsi0: Dumping Card State while idle, at SEQADDR > 0x9 > Feb 9 04:04:28 bar kernel: Card was paused > Feb 9 04:04:28 bar kernel: ACCUM = 0x4, SINDEX = 0x64, DINDEX = 0x65, ARG_2 = > 0x2 > Feb 9 04:04:28 bar kernel: HCNT = 0x0 SCBPTR = 0x6 > Feb 9 04:04:28 bar kernel: SCSIPHASE[0x0] SCSISIGI[0x0] ERROR[0x0] > SCSIBUSL[0x0] > Feb 9 04:04:28 bar kernel: LASTPHASE[0x1] SCSISEQ[0x12] SBLKCTL[0xa] > SCSIRATE[0x0] > Feb 9 04:04:28 bar kernel: SEQCTL[0x10] SEQ_FLAGS[0xc0] SSTAT0[0x0] > SSTAT1[0x8] > Feb 9 04:04:28 bar kernel: SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x8] SIMODE1[0xa4] > Feb 9 04:04:28 bar kernel: SXFRCTL0[0x80] DFCNTRL[0x0] DFSTATUS[0x89] > Feb 9 04:04:28 bar kernel: STACK: 0x0 0x163 0x178 0x3 > Feb 9 04:04:28 bar kernel: SCB count = 10 > Feb 9 04:04:28 bar kernel: Kernel NEXTQSCB = 7 > Feb 9 04:04:28 bar kernel: Card NEXTQSCB = 7 > Feb 9 04:04:28 bar kernel: QINFIFO entries: > Feb 9 04:04:28 bar kernel: Waiting Queue entries: > Feb 9 04:04:28 bar kernel: Disconnected Queue entries: 6:8 5:9 4:0 3:1 2:4 > 0:3 1:2 > Feb 9 04:04:28 bar kernel: QOUTFIFO entries: > Feb 9 04:04:28 bar kernel: Sequencer Free SCB List: 7 8 9 10 11 12 13 14 15 > 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 > Feb 9 04:04:28 bar kernel: Sequencer SCB Info: > Feb 9 04:04:28 bar kernel: 0 SCB_CONTROL[0x64] SCB_SCSIID[0x7] SCB_LUN[0x0] > SCB_TAG[0x3] > Feb 9 04:04:28 bar kernel: 1 SCB_CONTROL[0x64] SCB_SCSIID[0x7] SCB_LUN[0x0] > SCB_TAG[0x2] > Feb 9 04:04:28 bar kernel: 2 SCB_CONTROL[0x64] SCB_SCSIID[0x7] SCB_LUN[0x0] > SCB_TAG[0x4] > Feb 9 04:04:28 bar kernel: 3 SCB_CONTROL[0x64] SCB_SCSIID[0x7] SCB_LUN[0x0] > SCB_TAG[0x1] > Feb 9 04:04:28 bar kernel: 4 SCB_CONTROL[0x64] SCB_SCSIID[0x7] SCB_LUN[0x0] > SCB_TAG[0x0] > Feb 9 04:04:28 bar kernel: 5 SCB_CONTROL[0x64] SCB_SCSIID[0x7] SCB_LUN[0x0] > SCB_TAG[0x9] > Feb 9 04:04:28 bar kernel: 6 SCB_CONTROL[0x64] SCB_SCSIID[0x7] SCB_LUN[0x0] > SCB_TAG[0x8] > Feb 9 04:04:28 bar kernel: 7 SCB_CONTROL[0x0] SCB_SCSIID[0xff] > SCB_LUN[0xff] SCB_TAG[0xff] > Feb 9 04:04:28 bar kernel: 8 SCB_CONTROL[0x0] SCB_SCSIID[0xff] > SCB_LUN[0xff] SCB_TAG[0xff] > . > { ed: only number changes is 'X SCB_CONTROL'} > . > . > Feb 9 04:04:28 bar kernel: 30 SCB_CONTROL[0x0] SCB_SCSIID[0xff] > SCB_LUN[0xff] SCB_TAG[0xff] > Feb 9 04:04:28 bar kernel: 31 SCB_CONTROL[0x0] SCB_SCSIID[0xff] > SCB_LUN[0xff] SCB_TAG[0xff] > Feb 9 04:04:28 bar kernel: Pending list: > Feb 9 04:04:28 bar kernel: 8 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] > Feb 9 04:04:28 bar kernel: 9 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] > Feb 9 04:04:28 bar kernel: 0 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] > Feb 9 04:04:28 bar kernel: 1 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] > Feb 9 04:04:28 bar kernel: 4 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] > Feb 9 04:04:28 bar kernel: 3 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] > Feb 9 04:04:28 bar kernel: 2 SCB_CONTROL[0x60] SCB_SCSIID[0x7] SCB_LUN[0x0] > Feb 9 04:04:28 bar kernel: Kernel Free SCB list: 6 5 > Feb 9 04:04:28 bar kernel: DevQ(0:0:0): 0 waiting > Feb 9 04:04:28 bar kernel: > Feb 9 04:04:28 bar kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends > >>>>>>>>>>>>>>>>>> > Feb 9 04:04:28 bar kernel: (scsi0:A:0:0): Device is disconnected, re-queuing > SCB > Feb 9 04:04:28 bar kernel: Recovery code sleeping > Feb 9 04:04:28 bar kernel: (scsi0:A:0:0): Abort Tag Message Sent > Feb 9 04:04:28 bar kernel: (scsi0:A:0:0): SCB 3 - Abort Tag Completed. > Feb 9 04:04:28 bar kernel: Recovery SCB completes > Feb 9 04:04:28 bar kernel: Recovery code awake > Feb 9 04:04:28 bar kernel: aic7xxx_abort returns 0x2002 > {then begin again 21 times} > -- > Todd Denniston > Crane Division, Naval Surface Warfare Center (NSWC Crane) > Harnessing the Power of Technology for the Warfighter -- P. Larry Nelson (217-244-9855) | Systems/Network Administrator 461 Loomis Lab | U of I, CITES Departmental Services 1110 W. Green St., Urbana, IL | Consultant to: High Energy Physics Group MailTo:lnelson@uiuc.edu | http://www.uiuc.edu/ph/www/lnelson ------------------------------------------------------------------------- "Information without accountability is just noise." - P.L. Nelson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4027E33E.D0575293>