Adaptec 2940UW errors
 

I have a problem with my Adaptec 2940UW controller card. I had a Seagate 4.3UW drive (id:0), Plextor 40x max UW cdrom (id:3) on the 68 pin connector and a Plextor 12/10/32 CD-R (id:4) on the 50 pin connector. I have been running this setup for about 4 years now with no problems at all. I've used the 2.4.20 and 2.4.21 kernels both with apic and previous kernels without such support.

I just started to get the following errors when I rebooted the system:

Aug 24 14:28:18 storchnet kernel: scsi0:0:3:0: Attempting to queue an ABORT message
Aug 24 14:28:18 storchnet kernel: scsi0: Dumping Card State in Message-out phase, at SEQADDR 0x166
Aug 24 14:28:18 storchnet kernel: ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0xc0, ARG_2 = 0x0
Aug 24 14:28:18 storchnet kernel: HCNT = 0x0 SCBPTR = 0x0
Aug 24 14:28:18 storchnet kernel: SCSISEQ = 0x12, SBLKCTL = 0x2
Aug 24 14:28:18 storchnet kernel: DFCNTRL = 0x4, DFSTATUS = 0x6d
Aug 24 14:28:18 storchnet kernel: LASTPHASE = 0xa0, SCSISIGI = 0xb4, SXFRCTL0 = 0xa8
Aug 24 14:28:18 storchnet kernel: SSTAT0 = 0x5, SSTAT1 = 0x2
Aug 24 14:28:18 storchnet kernel: STACK == 0x190, 0x160, 0x0, 0xe4
Aug 24 14:28:18 storchnet kernel: SCB count = 4
Aug 24 14:28:18 storchnet kernel: Kernel NEXTQSCB = 3
Aug 24 14:28:18 storchnet kernel: Card NEXTQSCB = 3
Aug 24 14:28:18 storchnet kernel: QINFIFO entries:
Aug 24 14:28:18 storchnet kernel: Waiting Queue entries:
Aug 24 14:28:18 storchnet kernel: Disconnected Queue entries:
Aug 24 14:28:18 storchnet kernel: QOUTFIFO entries:
Aug 24 14:28:18 storchnet kernel: Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Aug 24 14:28:18 storchnet kernel: Sequencer SCB Info: 0(c 0x48, s 0x37, l 0, t 0x2) 1(c 0x0, s 0xff, l 255, t 0xff) 2(c 0x0, s 0xff, l 255, t 0xff) 3(c 0x0, s 0xff, l 255, t 0xff) 4(c 0x0, s 0xff, l 255, t 0xff) 5(c 0x0, s 0xff, l 255, t 0xff) 6(c 0x0, s 0xff, l 255, t 0xff) 7(c 0x0, s 0xff, l 255, t 0xff) 8(c 0x0, s 0xff, l 255, t 0xff) 9(c 0x0, s 0xff, l 255, t 0xff) 10(c 0x0, s
0xff, l 255, t 0xff) 11(c 0x0, s 0xff, l 255, t 0xff) 12(c 0x0, s 0xff, l 255, t 0xff) 13(c 0x0, s 0xff, l 255, t 0xff) 14(c 0x0, s 0xff, l 255, t 0xff) 15(c 0x0, s 0xff, l 255, t 0xff)
Aug 24 14:28:18 storchnet kernel: Pending list: 2(c 0x48, s 0x37, l 0)
Aug 24 14:28:18 storchnet kernel: Kernel Free SCB list: 1 0
Aug 24 14:28:18 storchnet kernel: Untagged Q(3): 2
Aug 24 14:28:18 storchnet kernel: DevQ(0:3:0): 0 waiting
Aug 24 14:28:18 storchnet kernel: scsi0:0:3:0: Device is active, asserting ATN
Aug 24 14:28:18 storchnet kernel: Recovery code sleeping


This goes on forever until I hit the reset button. I thought it was the Seagate drive failing, so I ripped it out and booted to an IDE drive with scsi moules as options and I still got the errors.

Googling the errors came up with nothing solid as an answer. Some said the aic7xxx driver was to blame, some said the hardware was the problem. The strange thing is the CD drives are still accessible in windows. Some times it takes longer to access, sometimes not.

Anyone else get errors like this with their SCSI controller (not just adaptec)? Is there a linux utility out there that can diagnose these errors better?

If it's the controller, anyone have a good suggestion for a cheap controller that will do ultra-wide and wide.

Forgot to mention:

Currently running Slack 9.0, Have used SuSe up to 6 something up to 7.3? with the same hardware. KT400 chipset mobo (current). Have used KT266 and KT266A mobos along with old K6-3d mobos.
1 gig ram

Hi..

This is HDD issue only. Replace the HDD

Siddiqu.T

Thanks, but it seems that the controller might also be on it's last leg as well. The HDD came off an old server that was always under heavy disk IO, so I'm happy it lasted this long.

I removed the HDD and I was still getting similar errors. I compiled the old adaptec 7xxx driver as a module, and it seemed to have fixed the card init errors when loading, but cdparanoia is now throwing fits.

I have read that some of the 2.4.22pre-kernels have some fixes for the 7xxx driver, I might just wait till then to really look at the issue, if not, then I might start to look for a replacement for this old card.