I am receiving the following messages in my system log when stress testing
with Cerberus (http://sourceforge.net/projects/va-ctcs). This is with an
onboard Adaptec 7902 Ultra 320 SCSI adapter. The messages are reproducible
on two different systems. This is with the 1.1.0 aic79xx driver, on
both the
stock Redhat kernel, and with a kernel compiled from the 2.4.19 sources.
The
system does not seem to be harmed by the messages, but I would like to
know if
they point to a problem or not. Interestingly, if I put and Adaptec
29320 PCI
card into the same machine, and use the same driver, the error is not
reproducible.
Mike
Jan 4 05:00:01 asl200 kernel: DevQ(0:2:0): 44 waiting
Jan 4 05:00:01 asl200 kernel: DevQ(0:6:0): 0 waiting
Jan 4 05:00:01 asl200 kernel: Abort called for cmd f78b5200
Jan 4 05:00:01 asl200 kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins
<<<<<<<<<<<<<<<<<
Jan 4 05:00:01 asl200 kernel: scsi0: Dumping Card State at program
address 0x71 Mode 0x22
Jan 4 05:00:02 asl200 kernel: SCSISEQ0[0x0]
SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI)
Jan 4 05:00:02 asl200 kernel: SEQINTCTL[0x80]:(INTVEC1DSL)
SCSISIGI[0x0]:(P_DATAOUT)
Jan 4 05:00:02 asl200 kernel: SCSIPHASE[0x0] SCSIBUS[0x0]
LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE)
Jan 4 05:00:02 asl200 kernel: SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0]
SSTAT0[0x0] SSTAT1[0x8]:(BUSFREE)
Jan 4 05:00:02 asl200 kernel: SSTAT2[0x0] SSTAT3[0x0]
PERRDIAG[0x8]:(AIPERR) SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO)
Jan 4 05:00:03 asl200 kernel: LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0]
LQOSTAT0[0x0]
Jan 4 05:00:03 asl200 kernel: LQOSTAT1[0x0] LQOSTAT2[0x1]:(LQOSTOP0)
Jan 4 05:00:03 asl200 kernel: SCB Count = 108 LASTSCB 0x30 CURRSCB 0x30
NEXTSCB 0xff00
Jan 4 05:00:03 asl200 kernel: qinstart = 21755 qinfifonext = 21755
Jan 4 05:00:03 asl200 kernel: QINFIFO:
Jan 4 05:00:03 asl200 kernel: WAITING_TID_QUEUES:
Jan 4 05:00:03 asl200 kernel: Pending list:
Jan 4 05:00:03 asl200 kernel: 67 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x43]
Jan 4 05:00:03 asl200 kernel: 55 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x37]
Jan 4 05:00:03 asl200 kernel: 26 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x1a]
Jan 4 05:00:03 asl200 kernel: 58 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x3a]
Jan 4 05:00:03 asl200 kernel: 0 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x0]
Jan 4 05:00:03 asl200 kernel: 31 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x1f]
Jan 4 05:00:03 asl200 kernel: 25 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x19]
Jan 4 05:00:03 asl200 kernel: 56 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x38]
Jan 4 05:00:03 asl200 kernel: 24 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x18]
Jan 4 05:00:03 asl200 kernel: 37 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x25]
Jan 4 05:00:03 asl200 kernel: 9 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x9]
Jan 4 05:00:03 asl200 kernel: 52 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x34]
Jan 4 05:00:03 asl200 kernel: 60 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x3c]
Jan 4 05:00:03 asl200 kernel: 47 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x2f]
Jan 4 05:00:03 asl200 kernel: 12 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0xc]
Jan 4 05:00:03 asl200 kernel: 43 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x2b]
Jan 4 05:00:03 asl200 kernel: 17 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x11]
Jan 4 05:00:03 asl200 kernel: 11 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0xb]
Jan 4 05:00:03 asl200 kernel: 32 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x20]
Jan 4 05:00:03 asl200 kernel: 50 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x32]
Jan 4 05:00:03 asl200 kernel: 16 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x10]
Jan 4 05:00:03 asl200 kernel: 8 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x8]
Jan 4 05:00:03 asl200 kernel: 57 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x39]
Jan 4 05:00:04 asl200 kernel: 14 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0xe]
Jan 4 05:00:04 asl200 kernel: 29 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x1d]
Jan 4 05:00:04 asl200 kernel: 33 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x21]
Jan 4 05:00:04 asl200 kernel: 61 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x3d]
Jan 4 05:00:04 asl200 kernel: 2 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x2]
Jan 4 05:00:06 asl200 kernel: 45 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x2d]
Jan 4 05:00:07 asl200 kernel: 19 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x13]
Jan 4 05:00:10 asl200 kernel: 3 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x3]
Jan 4 05:00:12 asl200 kernel: 53 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x35]
Jan 4 05:00:14 asl200 kernel: 34 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x22]
Jan 4 05:00:16 asl200 kernel: 15 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0xf]
Jan 4 05:00:18 asl200 kernel: 54 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x36]
Jan 4 05:00:18 asl200 kernel: 28 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x1c]
Jan 4 05:00:19 asl200 kernel: 59 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x3b]
Jan 4 05:00:20 asl200 kernel: 35 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x23]
Jan 4 05:00:21 asl200 kernel: 62 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x3e]
Jan 4 05:00:22 asl200 kernel: 5 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x5]
Jan 4 05:00:23 asl200 kernel: 39 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x27]
Jan 4 05:00:24 asl200 kernel: 49 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x31]
Jan 4 05:00:29 asl200 kernel: 40 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x28]
Jan 4 05:00:31 asl200 kernel: 30 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x1e]
Jan 4 05:00:40 asl200 kernel: 10 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0xa]
Jan 4 05:00:40 asl200 kernel: 20 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x14]
Jan 4 05:00:40 asl200 kernel: 18 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x12]
Jan 4 05:00:40 asl200 kernel: 4 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x4]
Jan 4 05:00:40 asl200 kernel: 1 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x1]
Jan 4 05:00:41 asl200 kernel: 44 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x2c]
Jan 4 05:00:41 asl200 kernel: 36 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x24]
Jan 4 05:00:42 asl200 kernel: 27 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x1b]
Jan 4 05:00:46 asl200 kernel: 22 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x16]
Jan 4 05:00:50 asl200 kernel: 23 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x17]
Jan 4 05:00:54 asl200 kernel: 51 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x33]
Jan 4 05:00:54 asl200 kernel: 42 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x2a]
Jan 4 05:00:55 asl200 kernel: 21 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x15]
Jan 4 05:00:55 asl200 kernel: 38 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x26]
Jan 4 05:00:55 asl200 kernel: 7 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x7]
Jan 4 05:00:56 asl200 kernel: 13 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0xd]
Jan 4 05:00:57 asl200 kernel: 46 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x2e]
Jan 4 05:00:59 asl200 kernel: 63 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB)
SCB_SCSIID[0x27] SCB_TAG[0x3f]
Jan 4 05:01:02 asl200 kernel: Kernel Free SCB list: 48 41 6 104 105 106
107 100 101 102 103 96 97 98 99 92 93 94 95 88 89 90 91 84 85 86 87 80
81 82 83 76 77 78 79 72 73 74 75 68 69 70 71 64 65 66
Jan 4 05:01:02 asl200 kernel: Sequencer Complete DMA-inprog list:
Jan 4 05:01:03 asl200 kernel: Sequencer Complete list:
Jan 4 05:01:03 asl200 kernel: Sequencer DMA-Up and Complete list:
Jan 4 05:01:03 asl200 kernel: scsi0: FIFO0 Free, LONGJMP == 0x825c, SCB
0x30, LJSCB 0x30
Jan 4 05:01:03 asl200 kernel:
SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS)
Jan 4 05:01:03 asl200 kernel: SEQINTSRC[0x0] DFCNTRL[0x0]
DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)
Jan 4 05:01:03 asl200 kernel: SG_CACHE_SHADOW[0x2]:(LAST_SEG)
SG_STATE[0x0] DFFSXFRCTL[0x0]
Jan 4 05:01:03 asl200 kernel: SOFFCNT[0x0]
MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0
Jan 4 05:01:03 asl200 kernel: HADDR = 0x00, HCNT =
0x0CCSGCTL[0x10]:(SG_CACHE_AVAIL)
Jan 4 05:01:03 asl200 kernel: scsi0: FIFO1 Free, LONGJMP == 0x8226, SCB
0x26, LJSCB 0x2e
Jan 4 05:01:03 asl200 kernel:
SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS)
Jan 4 05:01:03 asl200 kernel: SEQINTSRC[0x0] DFCNTRL[0x0]
DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)
Jan 4 05:01:03 asl200 kernel: SG_CACHE_SHADOW[0x2]:(LAST_SEG)
SG_STATE[0x0] DFFSXFRCTL[0x0]
Jan 4 05:01:03 asl200 kernel: SOFFCNT[0x0]
MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0
Jan 4 05:01:03 asl200 kernel: HADDR = 0x00, HCNT =
0x0CCSGCTL[0x10]:(SG_CACHE_AVAIL)
Jan 4 05:01:03 asl200 kernel: LQIN: 0x55 0x0 0x0 0x30 0x0 0x0 0x0 0x0
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0xc 0x0 0x0 0x0 0x0
Jan 4 05:01:03 asl200 kernel: scsi0: LQISTATE = 0x0, LQOSTATE = 0x0,
OPTIONMODE = 0x42
Jan 4 05:01:03 asl200 kernel: scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1
Jan 4 05:01:03 asl200 kernel: scsi0: REG0 == 0x30, SINDEX = 0x133,
DINDEX = 0x106
Jan 4 05:01:03 asl200 kernel: scsi0: SCBPTR == 0x30, SCB_NEXT ==
0xff80, SCB_NEXT2 == 0xff91
Jan 4 05:01:03 asl200 kernel: CDB 2a 0 0 85 86 e2
Jan 4 05:01:03 asl200 kernel: STACK: 0x1 0x104 0x0 0x0 0x21f 0x21f
0x25c 0x27
Jan 4 05:01:03 asl200 kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends
>>>>>>>>>>>>>>>>>>
Jan 4 05:01:03 asl200 kernel: DevQ(0:2:0): 44 waiting
Jan 4 05:01:03 asl200 kernel: DevQ(0:6:0): 0 waiting
Jan 4 05:01:03 asl200 kernel: dev reset called for cmd f7880000
Jan 4 05:01:03 asl200 kernel: bus reset called for cmd f7880000
Jan 4 05:01:03 asl200 kernel: (scsi0:A:2:0): Now packetized.
> I am receiving the following messages in my system log when stress testing
> with Cerberus (http://sourceforge.net/projects/va-ctcs). This is with an
> onboard Adaptec 7902 Ultra 320 SCSI adapter. The messages are
> reproducible on two different systems. This is with the 1.1.0 aic79xx
> driver, on both the stock Redhat kernel, and with a kernel compiled from
> the 2.4.19 sources. The system does not seem to be harmed by the
> messages, but I would like to know if they point to a problem or not.
> Interestingly, if I put and Adaptec 29320 PCI card into the same machine,
> and use the same driver, the error is not reproducible.
I would need to see *all* of the messages in order to tell you what they
mean. The log is truncated. Perhaps you can send me the full output
off list since it may be large?
--
Justin
Hi,
We may be experiencing the same problem.
In our case it results in the SEAGATE ST336607LW drive locking up solid
with no hardware reset possible.
Our problem is that our 320MB/s SEAGATE ST336607LW drive will lockup
after about 10mins to 2hours of serious activity (Copying disk partitions).
.
The primary error message we see is:
"Saw underflow (16384 of 20480 bytes). Treated as error"
followed by various SCSI error messages. The SCSI disks LED
remains on and it is impossible to access the SCSI disk. The system
will then hang. Reseting the system does not clear the SCSI disk LED and
the SCSI disk is not seen in the Adaptec BIOS on startup. A power off/on
cycle will clear the condition.
We have been trying to track down the problem for about two weeks now
and we are still unsure where the problem lies: Disk, SCSI cable, SCSI
controller or Linux driver.
Some info we do have though is:
1. Setting the SCSI bus speed from 320MB/s to 160MB/s does not affect
the problem.
2. Switching off packetized mode fixes the problem (we think).
3. Using a non SMP kernel may fix the problem (we are testing at this
moment).
Our system is:
System: Dual Xeon 2.4GHz system using SuperMicro X5DA8 Motherboard.
SCSI: Adaptec 7902 onboard dual channel SCSI controller
Disks: 2 off Quantum Atlas 10K2 18G (160LW), 1 of Quantum 9G (80LW)
Disks: 1 off Seagate ST336607LW 36G (320LW)
System: RedHat 7.3 with updates to 18/02/03
Kernel: 2.4.18-24.7.xsmp
Aic79xx Driver: versions 1.0.0 and 1.1.0
Our current view is that there are two problems:
1. There is a timing/SMP issue with the Linux AIC79XX SCSI driver in SMP
systems that cause and incorect SCSI bus condition.
2. The SEAGATE ST336607LW responds to this condition by locking up and
cannot be reset. We have information from Seagate that it is possible
for the ST336607LW to get in a condition where it cannot be reset !
We have had a lot of communications with Seagate on this so far to no
avail. We have quite a lot of information in terms of log files etc.
Is there a good contact for someone who knows about the Adaptec AIC79XX
driver that we could talk to ?
Any help would be appreciated.
Terry
> I am receiving the following messages in my system log when stress testing
> with Cerberus (http://sourceforge.net/projects/va-ctcs). This is with an
> onboard Adaptec 7902 Ultra 320 SCSI adapter. The messages are reproducible
> on two different systems. This is with the 1.1.0 aic79xx driver, on
> both the
> stock Redhat kernel, and with a kernel compiled from the 2.4.19 sources.
> The
> system does not seem to be harmed by the messages, but I would like to
> know if
> they point to a problem or not. Interestingly, if I put and Adaptec
> 29320 PCI
> card into the same machine, and use the same driver, the error is not
> reproducible.
>
> Mike
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: [email protected] Web: http://www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
"Tandems are twice the fun !"
> Our system is:
> System: Dual Xeon 2.4GHz system using SuperMicro X5DA8 Motherboard.
> SCSI: Adaptec 7902 onboard dual channel SCSI controller
> Disks: 2 off Quantum Atlas 10K2 18G (160LW), 1 of Quantum 9G (80LW)
> Disks: 1 off Seagate ST336607LW 36G (320LW)
> System: RedHat 7.3 with updates to 18/02/03
> Kernel: 2.4.18-24.7.xsmp
> Aic79xx Driver: versions 1.0.0 and 1.1.0
Is there some reason why you are using such old versions of the aic79xx
driver? You can obtain the latest version of the driver from here:
http://people.FreeBSD.org/~gibbs/linux/RPM/aic79xx/
http://people.FreeBSD.org/~gibbs/linux/DUD/aic79xx/
or in source form for a 2.4.X or 2.5.X kernel from here:
http://people.freebsd.org/~gibbs/linux/SRC/
--
Justin
Hi Justin,
Thanks for the info.
We were using these drivers as:
1. The 1.0.0 driver is as used in the Stock Redhat 7.3 release (updated
to current updates).
2. The 1.1.0 driver is on the Adaptec web site for Linux and is I
believe the one shipped on there CDROM for the on-board 7902
controller.
We were not aware of a later driver.
For future reference, where should we go to find the latest drivers
for any device for the linux 2.4.x kernel ?
Do you know if the latest driver at
http://people.FreeBSD.org/~gibbs/linux/RPM/aic79xx/
might fix this problem ?
Cheers
Terry
Justin T. Gibbs wrote:
>>Our system is:
>>System: Dual Xeon 2.4GHz system using SuperMicro X5DA8 Motherboard.
>>SCSI: Adaptec 7902 onboard dual channel SCSI controller
>>Disks: 2 off Quantum Atlas 10K2 18G (160LW), 1 of Quantum 9G (80LW)
>>Disks: 1 off Seagate ST336607LW 36G (320LW)
>>System: RedHat 7.3 with updates to 18/02/03
>>Kernel: 2.4.18-24.7.xsmp
>>Aic79xx Driver: versions 1.0.0 and 1.1.0
>
>
> Is there some reason why you are using such old versions of the aic79xx
> driver? You can obtain the latest version of the driver from here:
>
> http://people.FreeBSD.org/~gibbs/linux/RPM/aic79xx/
> http://people.FreeBSD.org/~gibbs/linux/DUD/aic79xx/
>
> or in source form for a 2.4.X or 2.5.X kernel from here:
>
> http://people.freebsd.org/~gibbs/linux/SRC/
>
> --
> Justin
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: [email protected] Web: http://www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
"Tandems are twice the fun !"
Hi Michael,
The Seagate ST336607LW has firmware: 0004.
Seagate have stated to me that this is the latest.
They have also stated to me:
Issuing an unrecognized or illegal command to the drive can cause the
drive to go into a hardware fault mode where it will no longer respond,
and may or may not respond to a SCSI BUS reset. It seems, in this case,
the drive will no longer respond to any commands issued by the
controller.
Is this "feature" now common on SCSI drives ????
Terry
Michael Madore wrote:
> Also, what version of firmware do your drives have? Our original
> problems stemmed from buggy firmware. Seagate have updated firmware
> which you can request from their technical support.
>
> Mike
>
> Justin T. Gibbs wrote:
>
>>> Our system is:
>>> System: Dual Xeon 2.4GHz system using SuperMicro X5DA8 Motherboard.
>>> SCSI: Adaptec 7902 onboard dual channel SCSI controller
>>> Disks: 2 off Quantum Atlas 10K2 18G (160LW), 1 of Quantum 9G (80LW)
>>> Disks: 1 off Seagate ST336607LW 36G (320LW)
>>> System: RedHat 7.3 with updates to 18/02/03
>>> Kernel: 2.4.18-24.7.xsmp
>>> Aic79xx Driver: versions 1.0.0 and 1.1.0
>>>
>>
>>
>> Is there some reason why you are using such old versions of the aic79xx
>> driver? You can obtain the latest version of the driver from here:
>>
>> http://people.FreeBSD.org/~gibbs/linux/RPM/aic79xx/
>> http://people.FreeBSD.org/~gibbs/linux/DUD/aic79xx/
>>
>> or in source form for a 2.4.X or 2.5.X kernel from here:
>>
>> http://people.freebsd.org/~gibbs/linux/SRC/
>>
>> --
>> Justin
>>
>>
>
>
>
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: [email protected] Web: http://www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
"Tandems are twice the fun !"
Also, what version of firmware do your drives have? Our original
problems stemmed from buggy firmware. Seagate have updated firmware
which you can request from their technical support.
Mike
Justin T. Gibbs wrote:
>>Our system is:
>>System: Dual Xeon 2.4GHz system using SuperMicro X5DA8 Motherboard.
>>SCSI: Adaptec 7902 onboard dual channel SCSI controller
>>Disks: 2 off Quantum Atlas 10K2 18G (160LW), 1 of Quantum 9G (80LW)
>>Disks: 1 off Seagate ST336607LW 36G (320LW)
>>System: RedHat 7.3 with updates to 18/02/03
>>Kernel: 2.4.18-24.7.xsmp
>>Aic79xx Driver: versions 1.0.0 and 1.1.0
>>
>>
>
>Is there some reason why you are using such old versions of the aic79xx
>driver? You can obtain the latest version of the driver from here:
>
>http://people.FreeBSD.org/~gibbs/linux/RPM/aic79xx/
>http://people.FreeBSD.org/~gibbs/linux/DUD/aic79xx/
>
>or in source form for a 2.4.X or 2.5.X kernel from here:
>
>http://people.freebsd.org/~gibbs/linux/SRC/
>
>--
>Justin
>
>
> Hi Justin,
>
> Thanks for the info.
> We were using these drivers as:
>
> 1. The 1.0.0 driver is as used in the Stock Redhat 7.3 release (updated
> to current updates).
Unfortunately, providing updates to Redhat even in a timely manner has
no impact on whether or not these udpates are incorporated into recent
releases.
> 2. The 1.1.0 driver is on the Adaptec web site for Linux and is I believe the one shipped on there CDROM for the on-board 7902
> controller.
Getting website updates is a slow and painful process at Adaptec.
I've been working on this for some time, but have not yet had any
success. That is why I distribute the most recent drivers from
a location I can control.
> We were not aware of a later driver.
> For future reference, where should we go to find the latest drivers
> for any device for the linux 2.4.x kernel ?
That would depend on the device. For Adaptec aic7xxx and aic79xx drivers,
you can use the site I provided.
> Do you know if the latest driver at
> http://people.FreeBSD.org/~gibbs/linux/RPM/aic79xx/ might fix
> this problem ?
I don't know enough about your problem to be able to say. There have
been lots of fixes to these drivers over their lifetime, so upgrading
is a good first step.
--
Justin
> Hi Michael,
>
> The Seagate ST336607LW has firmware: 0004.
> Seagate have stated to me that this is the latest.
> They have also stated to me:
>
> Issuing an unrecognized or illegal command to the drive can cause the
> drive to go into a hardware fault mode where it will no longer respond,
> and may or may not respond to a SCSI BUS reset. It seems, in this case,
> the drive will no longer respond to any commands issued by the
> controller.
>
> Is this "feature" now common on SCSI drives ????
This would be a terrible violation of the SCSI spec. Perhaps someone
forgot to disable a debugging mode in the drive?
--
Justin
On Fri, Mar 14, 2003 at 04:17:59PM +0000, Terry Barnaby wrote:
> The Seagate ST336607LW has firmware: 0004.
> Seagate have stated to me that this is the latest.
> They have also stated to me:
>
> Issuing an unrecognized or illegal command to the drive can cause the
> drive to go into a hardware fault mode where it will no longer respond,
> and may or may not respond to a SCSI BUS reset. It seems, in this case,
> the drive will no longer respond to any commands issued by the
> controller.
>
> Is this "feature" now common on SCSI drives ????
Could we add a KERN_WARNING printk in sd.c quoting/referencing
this message on inquiry detecting this device?
So sysadmins who are used to SCSI being robust could return the
drive to their vendors in exchange to a drive working along the
SCSI specs after reading this message.
Thanks in the name of the sysadmins.
Regards
Ingo Oeser
Ingo,
Our testing with that drive (same firmware, using same aic7902 chipset) has
not shown any problems like this. However, we were using a later aic79xx
driver versions (1.3.x). That upgrade should be the first step.
I wouldn't get too excited about the statement by a level-1 Seagate support
guy, probably just a blanket statement when they want to disclaim
responsibility.
Andy
-----Original Message-----
From: Ingo Oeser [mailto:[email protected]]
Sent: Saturday, March 15, 2003 8:12 AM
To: Terry Barnaby
Cc: Michael Madore; Justin T. Gibbs; [email protected]
Subject: Re: Reproducible SCSI Error with Adaptec 7902
On Fri, Mar 14, 2003 at 04:17:59PM +0000, Terry Barnaby wrote:
> The Seagate ST336607LW has firmware: 0004.
> Seagate have stated to me that this is the latest.
> They have also stated to me:
>
> Issuing an unrecognized or illegal command to the drive can cause the
> drive to go into a hardware fault mode where it will no longer respond,
> and may or may not respond to a SCSI BUS reset. It seems, in this case,
> the drive will no longer respond to any commands issued by the
> controller.
>
> Is this "feature" now common on SCSI drives ????
Could we add a KERN_WARNING printk in sd.c quoting/referencing
this message on inquiry detecting this device?
So sysadmins who are used to SCSI being robust could return the
drive to their vendors in exchange to a drive working along the
SCSI specs after reading this message.
Thanks in the name of the sysadmins.
Regards
Ingo Oeser
Hi Andy,
We have just updated to the latest driver 1.3.4. This has stopped the
drive locking up, but we are now getting nasty SCSI error reports
in /var/log/messages. Will continue to delve into this.
However, what ever the fault that triggers our drive to lock-up, the
drive certainly locks up. It locks up with LED on and will not respond
to a SCSI bus reset. We need to power cycle the system to get the drive
working again. We have tried two Seagate ST336607LW drives both exibit
the same behaviour. It appears to only happen when Linux is running in
SMP mode and when the drive is running in packetized mode.
So there is certainly the possibility of the Seagate ST336607LW not
responding to resets. This may be a firmware fault so we have talked
to Seagate about the issue. The statement is the result of our direct
question:
> I realise that the problem could be due to the Linux SCSI driver, the Motherboard SCSI controller, the SCSI lead or the drive. We are used to
> tracking down such nasty problems. However, I have one firm pointer:
>
> 1. Once the drive is locked up, with its LED on, a SCSI bus reset will
> not clear the drive. A full poweroff/poweron cycle is needed.
>
> So I ask again, is there a case where the drive will not respond to a
> SCSI bus reset ?
Is there any way of getting this information to higher level Seagate
support ?
Terry
Cress, Andrew R wrote:
> Ingo,
>
> Our testing with that drive (same firmware, using same aic7902 chipset) has
> not shown any problems like this. However, we were using a later aic79xx
> driver versions (1.3.x). That upgrade should be the first step.
>
> I wouldn't get too excited about the statement by a level-1 Seagate support
> guy, probably just a blanket statement when they want to disclaim
> responsibility.
>
> Andy
>
> -----Original Message-----
> From: Ingo Oeser [mailto:[email protected]]
> Sent: Saturday, March 15, 2003 8:12 AM
> To: Terry Barnaby
> Cc: Michael Madore; Justin T. Gibbs; [email protected]
> Subject: Re: Reproducible SCSI Error with Adaptec 7902
>
>
> On Fri, Mar 14, 2003 at 04:17:59PM +0000, Terry Barnaby wrote:
>
>>The Seagate ST336607LW has firmware: 0004.
>>Seagate have stated to me that this is the latest.
>>They have also stated to me:
>>
>> Issuing an unrecognized or illegal command to the drive can cause the
>> drive to go into a hardware fault mode where it will no longer respond,
>> and may or may not respond to a SCSI BUS reset. It seems, in this case,
>> the drive will no longer respond to any commands issued by the
>> controller.
>>
>>Is this "feature" now common on SCSI drives ????
>
>
> Could we add a KERN_WARNING printk in sd.c quoting/referencing
> this message on inquiry detecting this device?
>
> So sysadmins who are used to SCSI being robust could return the
> drive to their vendors in exchange to a drive working along the
> SCSI specs after reading this message.
>
> Thanks in the name of the sysadmins.
>
> Regards
>
> Ingo Oeser
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: [email protected] Web: http://www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
"Tandems are twice the fun !"
Mar 16 05:20:39 beam kernel: kjournald starting. Commit interval 5 seconds
Mar 16 05:20:39 beam kernel: EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,55), internal journal
Mar 16 05:20:39 beam kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 16 05:30:29 beam kernel: kjournald starting. Commit interval 5 seconds
Mar 16 05:30:29 beam kernel: EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,50), internal journal
Mar 16 05:30:29 beam kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 16 05:33:11 beam kernel: scsi0: Unexpected PKT busfree condition
Mar 16 05:33:11 beam kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
Mar 16 05:33:11 beam kernel: scsi0: Dumping Card State at program address 0x8f Mode 0x11
Mar 16 05:33:11 beam kernel: Card was paused
Mar 16 05:33:11 beam kernel: HS_MAILBOX[0x40] INTCTL[0xc0] SEQINTSTAT[0x0] SAVED_MODE[0x11]
Mar 16 05:33:11 beam kernel: DFFSTAT[0x0] SCSISIGI[0x26] SCSIPHASE[0x1] SCSIBUS[0x0]
Mar 16 05:33:11 beam kernel: LASTPHASE[0x1] SCSISEQ0[0x0] SCSISEQ1[0x12] SEQCTL0[0x10]
Mar 16 05:33:11 beam kernel: SEQINTCTL[0x88] SEQ_FLAGS[0xc0] SEQ_FLAGS2[0x0] SSTAT0[0x0]
Mar 16 05:33:11 beam kernel: SSTAT1[0x19] SSTAT2[0x0] SSTAT3[0x80] PERRDIAG[0x0]
Mar 16 05:33:11 beam kernel: SIMODE1[0xa4] LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x1]
Mar 16 05:33:11 beam kernel: LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x81]
Mar 16 05:33:11 beam kernel:
Mar 16 05:33:11 beam kernel: SCB Count = 240 CMDS_PENDING = 49 LASTSCB 0x46 CURRSCB 0x46 NEXTSCB 0xff80
Mar 16 05:33:11 beam kernel: qinstart = 30076 qinfifonext = 30076
Mar 16 05:33:11 beam kernel: QINFIFO:
Mar 16 05:33:11 beam kernel: WAITING_TID_QUEUES:
Mar 16 05:33:11 beam kernel: Pending list:
Mar 16 05:33:11 beam kernel: 38 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x26]
Mar 16 05:33:11 beam kernel: 32 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x20]
Mar 16 05:33:11 beam kernel: 79 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x4f]
Mar 16 05:33:11 beam kernel: 219 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xdb]
Mar 16 05:33:11 beam kernel: 216 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xd8]
Mar 16 05:33:11 beam kernel: 15 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xf]
Mar 16 05:33:11 beam kernel: 134 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x86]
Mar 16 05:33:11 beam kernel: 85 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x55]
Mar 16 05:33:11 beam kernel: 136 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x88]
Mar 16 05:33:11 beam kernel: 215 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xd7]
Mar 16 05:33:11 beam kernel: 12 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xc]
Mar 16 05:33:11 beam kernel: 106 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x6a]
Mar 16 05:33:11 beam kernel: 65 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x41]
Mar 16 05:33:11 beam kernel: 162 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xa2]
Mar 16 05:33:11 beam kernel: 112 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x70]
Mar 16 05:33:11 beam kernel: 66 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x42]
Mar 16 05:33:11 beam kernel: 137 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x89]
Mar 16 05:33:11 beam kernel: 146 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x92]
Mar 16 05:33:11 beam kernel: 203 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xcb]
Mar 16 05:33:11 beam kernel: 167 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xa7]
Mar 16 05:33:11 beam kernel: 133 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x85]
Mar 16 05:33:11 beam kernel: 117 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x75]
Mar 16 05:33:11 beam kernel: 154 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x9a]
Mar 16 05:33:11 beam kernel: 196 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xc4]
Mar 16 05:33:11 beam kernel: 138 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x8a]
Mar 16 05:33:11 beam kernel: 89 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x59]
Mar 16 05:33:11 beam kernel: 55 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x37]
Mar 16 05:33:11 beam kernel: 6 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x6]
Mar 16 05:33:11 beam kernel: 199 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xc7]
Mar 16 05:33:11 beam kernel: 166 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xa6]
Mar 16 05:33:11 beam kernel: 110 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x6e]
Mar 16 05:33:11 beam kernel: 155 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x9b]
Mar 16 05:33:11 beam kernel: 213 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xd5]
Mar 16 05:33:11 beam kernel: 212 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xd4]
Mar 16 05:33:11 beam kernel: 201 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xc9]
Mar 16 05:33:11 beam kernel: 56 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x38]
Mar 16 05:33:11 beam kernel: 10 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xa]
Mar 16 05:33:11 beam kernel: 16 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x10]
Mar 16 05:33:11 beam kernel: 13 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xd]
Mar 16 05:33:11 beam kernel: 68 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x44]
Mar 16 05:33:11 beam kernel: 206 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xce]
Mar 16 05:33:11 beam kernel: 198 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xc6]
Mar 16 05:33:11 beam kernel: 152 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x98]
Mar 16 05:33:11 beam kernel: 40 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x28]
Mar 16 05:33:11 beam kernel: 50 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x32]
Mar 16 05:33:11 beam kernel: 205 SCB_CONTROL[0x64] SCB_SCSIID[0x7] SCB_TAG[0xcd]
Mar 16 05:33:11 beam kernel: 142 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x8e]
Mar 16 05:33:11 beam kernel: 188 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xbc]
Mar 16 05:33:11 beam kernel: 18 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x12]
Mar 16 05:33:11 beam kernel: Total 49
Mar 16 05:33:11 beam kernel: Kernel Free SCB list: 70 5 153 27 101 64 214 121 195 73 113 164 140 184 63 120 192 163 190 127 30 41 180 171 143 218 14 128 46 35 179 156 197 147 118 4 108 204 31 45 130 125 183 7 72 139 58 42 44 48 178 209 202 67 114 62 194 175 129 71 29 111 39 177 200 191 126 100 104 26 33 157 36 189 78 93 141 9 43 145 207 22 150 1 19 222 86 69 59 105 165 8 149 119 11 107 132 208 2 217 57 54 131 116 51 211 135 172 144 221 61 76 159 109 193 74 148 115 75 151 84 52 88 210 53 25 124 223 47 123 186 181 185 187 83 90 80 182 77 81 176 87 173 95 91 174 82 170 94 168 97 92 169 98 160 99 96 161 102 34 103 158 28 37 0 220 17 23 20 239 232 233 234 235 228 229 230 231 224 225 226 227 49 24 60 3 21 122 238 237 236
Mar 16 05:33:11 beam kernel: Sequencer Complete DMA-inprog list:
Mar 16 05:33:11 beam kernel: Sequencer Complete list:
Mar 16 05:33:11 beam kernel: Sequencer DMA-Up and Complete list:
Mar 16 05:33:11 beam kernel:
Mar 16 05:33:11 beam kernel: scsi0: FIFO0 Active, LONGJMP == 0x8283, SCB 0xbc, LJSCB 0x8c
Mar 16 05:33:11 beam kernel: SEQIMODE[0x3f] SEQINTSRC[0x10] DFCNTRL[0x4] DFSTATUS[0x89]
Mar 16 05:33:11 beam kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0]
Mar 16 05:33:11 beam kernel: SOFFCNT[0x3f] MDFFSTAT[0x2] SHADDR = 0x00, SHCNT = 0x0
Mar 16 05:33:11 beam kernel: HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
Mar 16 05:33:11 beam kernel: scsi0: FIFO1 Active, LONGJMP == 0x25c, SCB 0x12, LJSCB 0x12
Mar 16 05:33:11 beam kernel: SEQIMODE[0x3f] SEQINTSRC[0x40] DFCNTRL[0xc] DFSTATUS[0x89]
Mar 16 05:33:11 beam kernel: SG_CACHE_SHADOW[0x23] SG_STATE[0x0] DFFSXFRCTL[0x0]
Mar 16 05:33:11 beam kernel: SOFFCNT[0x3f] MDFFSTAT[0x16] SHADDR = 0x02b85c000, SHCNT = 0x0
Mar 16 05:33:11 beam kernel: HADDR = 0x02b85c000, HCNT = 0x0 CCSGCTL[0x0]
Mar 16 05:33:11 beam kernel: LQIN: 0x5 0x0 0x0 0xbc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0 0x0 0x0 0x2 0x0
Mar 16 05:33:11 beam kernel: scsi0: LQISTATE = 0x25, LQOSTATE = 0x0, OPTIONMODE = 0x42
Mar 16 05:33:11 beam kernel: scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1
Mar 16 05:33:11 beam kernel: SIMODE0[0xc]
Mar 16 05:33:11 beam kernel: CCSCBCTL[0x0]
Mar 16 05:33:11 beam kernel: scsi0: REG0 == 0x60, SINDEX = 0x122, DINDEX = 0x108
Mar 16 05:33:11 beam kernel: scsi0: SCBPTR == 0x12, SCB_NEXT == 0xffc0, SCB_NEXT2 == 0xfffc
Mar 16 05:33:11 beam kernel: CDB 2a 0 0 80 20 e8
Mar 16 05:33:11 beam kernel: STACK: 0x2e 0x10 0x2e 0x10 0x1 0x25c 0x28f 0x255
Mar 16 05:33:11 beam kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
Mar 16 05:33:11 beam kernel: DevQ(0:0:0): 0 waiting
Mar 16 05:33:11 beam kernel: DevQ(0:1:0): 0 waiting
Mar 16 05:33:11 beam kernel: DevQ(0:2:0): 0 waiting
Mar 16 05:33:11 beam kernel: DevQ(0:3:0): 0 waiting
Mar 16 05:37:55 beam kernel: kjournald starting. Commit interval 5 seconds
Mar 16 05:37:55 beam kernel: EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,55), internal journal
Mar 16 05:37:55 beam kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 16 05:47:40 beam kernel: kjournald starting. Commit interval 5 seconds
Mar 16 05:47:40 beam kernel: EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,50), internal journal
Mar 16 05:47:40 beam kernel: EXT3-fs: mounted filesystem with ordered data mode.
> 1. Would it be possible for you to look at the error message to see
> what it is related to.
The drive has unexpectedly dropped off the bus during a connection.
Without a SCSI bus trace it is impossible to know why the drive might
have done this or if perhaps a glitch on the BSY line is causing the
controller to detect a spurious busfree.
> 2. Would it be possible to determine what may have locked up the drive
> with the previous SCSI driver. I could feed this back to Seagate.
I have my hands too full trying to replicate problems seen with the
latest driver and debug their cause to go back and try and figure
out what an old driver version might have done to upset a drive.
--
Justin
Hi,
We have continued to try and get to the bottom of the problem we have
with the Seagate ST336607LW drive with an Adaptec 7902 SCSI controller
under Linux on an SMP machine. We have recently tried the latest
Adaptec Linux driver (1.3.4) from Justin Gibbs who is one of the Adaptec
SCSI driver developers. This has stopped the drive locking up but now
lists SCSI errors in the log files. I enclose a portion of this log
file. I have run the error logs past Justin and he has stated:
"The drive has unexpectedly dropped off the bus during a connection.
Without a SCSI bus trace it is impossible to know why the drive might
have done this or if perhaps a glitch on the BSY line is causing the
controller to detect a spurious busfree."
My current conclusions are:
1. The Seagate ST336607LW drive has a bug where in certain circumstances
the drive can lock up, with LED on. In this state it will not
respond to a hardware reset and a power off/on cycle is needed to
reset the drive. There is a difference between the way the Linux
Adaptec AIC79XX 1.1.0 driver and the 1.3.4 driver handles a SCSI
error condition that triggers this behaviour.
2. There is a problem with one of the following: The Seagate ST336607LW drive,
the Adaptec 7902 SCSI controller on the SuperMicro X5DA8 Motherboard or
the Linux AIC79XX driver that causes a SCSI bus fault.
I am now giving up with Seagate ST336607LW drive and intend to try a
Maxtor Atlas 10K IV drive instead.
I include this information to hopefully assist others who may encounter this
problem and to list the bugs so that those who are in a position to fix them
know about it.
Terry
-------------------------------------------------------------------------
The System:
System: Dual Xeon 2.4GHz system using SuperMicro X5DA8 Motherboard.
SCSI: Adaptec 7902 onboard dual channel SCSI controller
Disks: 2 off Quantum Atlas 10K2 18G (160LW), 1 of Quantum 9G (80LW)
Disks: 1 off Seagate ST336607LW 36G (320LW)
System: RedHat 7.3 with updates to 18/02/03
Kernel: 2.4.18-24.7.xsmp
Adaptec Driver: AIC79XX 1.0.0, 1.1.0 and 1.3.4
The problem with Adaptec Drivers 1.0.0 and 1.1.0
If I start off a disk to disk copy of a large amount of information,
after about 10mins the SCSI disk will lock up. I get the kernel message
"Saw underflow (16384 of 20480 bytes). Treated as error" followed by various
SCSI error messages. The SCSI disks LED remains on and it is impossible to
access the SCSI disk. Resetimg the system does not clear the SCSI disk LED and the SCSI
disk is not seen in the Adaptec BIOS on startup. A power off/on cycle
will clear the condition.
The problem with Adaptec Drivers 1.3.4
If I start off a disk to disk copy of a large amount of information,
after about 10mins I will get error messages in the system log /var/log/messages.
Log entries listed below:
Portion of Linux's /var/log/messages
Mar 16 05:20:39 beam kernel: kjournald starting. Commit interval 5 seconds
Mar 16 05:20:39 beam kernel: EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,55), internal journal
Mar 16 05:20:39 beam kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 16 05:30:29 beam kernel: kjournald starting. Commit interval 5 seconds
Mar 16 05:30:29 beam kernel: EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,50), internal journal
Mar 16 05:30:29 beam kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 16 05:33:11 beam kernel: scsi0: Unexpected PKT busfree condition
Mar 16 05:33:11 beam kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
Mar 16 05:33:11 beam kernel: scsi0: Dumping Card State at program address 0x8f Mode 0x11
Mar 16 05:33:11 beam kernel: Card was paused
Mar 16 05:33:11 beam kernel: HS_MAILBOX[0x40] INTCTL[0xc0] SEQINTSTAT[0x0] SAVED_MODE[0x11]
Mar 16 05:33:11 beam kernel: DFFSTAT[0x0] SCSISIGI[0x26] SCSIPHASE[0x1] SCSIBUS[0x0]
Mar 16 05:33:11 beam kernel: LASTPHASE[0x1] SCSISEQ0[0x0] SCSISEQ1[0x12] SEQCTL0[0x10]
Mar 16 05:33:11 beam kernel: SEQINTCTL[0x88] SEQ_FLAGS[0xc0] SEQ_FLAGS2[0x0] SSTAT0[0x0]
Mar 16 05:33:11 beam kernel: SSTAT1[0x19] SSTAT2[0x0] SSTAT3[0x80] PERRDIAG[0x0]
Mar 16 05:33:11 beam kernel: SIMODE1[0xa4] LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x1]
Mar 16 05:33:11 beam kernel: LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x81]
Mar 16 05:33:11 beam kernel:
Mar 16 05:33:11 beam kernel: SCB Count = 240 CMDS_PENDING = 49 LASTSCB 0x46 CURRSCB 0x46 NEXTSCB 0xff80
Mar 16 05:33:11 beam kernel: qinstart = 30076 qinfifonext = 30076
Mar 16 05:33:11 beam kernel: QINFIFO:
Mar 16 05:33:11 beam kernel: WAITING_TID_QUEUES:
Mar 16 05:33:11 beam kernel: Pending list:
Mar 16 05:33:11 beam kernel: 38 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x26]
Mar 16 05:33:11 beam kernel: 32 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x20]
Mar 16 05:33:11 beam kernel: 79 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x4f]
Mar 16 05:33:11 beam kernel: 219 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xdb]
Mar 16 05:33:11 beam kernel: 216 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xd8]
Mar 16 05:33:11 beam kernel: 15 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xf]
Mar 16 05:33:11 beam kernel: 134 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x86]
Mar 16 05:33:11 beam kernel: 85 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x55]
Mar 16 05:33:11 beam kernel: 136 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x88]
Mar 16 05:33:11 beam kernel: 215 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xd7]
Mar 16 05:33:11 beam kernel: 12 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xc]
Mar 16 05:33:11 beam kernel: 106 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x6a]
Mar 16 05:33:11 beam kernel: 65 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x41]
Mar 16 05:33:11 beam kernel: 162 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xa2]
Mar 16 05:33:11 beam kernel: 112 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x70]
Mar 16 05:33:11 beam kernel: 66 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x42]
Mar 16 05:33:11 beam kernel: 137 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x89]
Mar 16 05:33:11 beam kernel: 146 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x92]
Mar 16 05:33:11 beam kernel: 203 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xcb]
Mar 16 05:33:11 beam kernel: 167 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xa7]
Mar 16 05:33:11 beam kernel: 133 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x85]
Mar 16 05:33:11 beam kernel: 117 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x75]
Mar 16 05:33:11 beam kernel: 154 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x9a]
Mar 16 05:33:11 beam kernel: 196 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xc4]
Mar 16 05:33:11 beam kernel: 138 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x8a]
Mar 16 05:33:11 beam kernel: 89 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x59]
Mar 16 05:33:11 beam kernel: 55 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x37]
Mar 16 05:33:11 beam kernel: 6 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x6]
Mar 16 05:33:11 beam kernel: 199 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xc7]
Mar 16 05:33:11 beam kernel: 166 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xa6]
Mar 16 05:33:11 beam kernel: 110 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x6e]
Mar 16 05:33:11 beam kernel: 155 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x9b]
Mar 16 05:33:11 beam kernel: 213 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xd5]
Mar 16 05:33:11 beam kernel: 212 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xd4]
Mar 16 05:33:11 beam kernel: 201 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xc9]
Mar 16 05:33:11 beam kernel: 56 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x38]
Mar 16 05:33:11 beam kernel: 10 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xa]
Mar 16 05:33:11 beam kernel: 16 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x10]
Mar 16 05:33:11 beam kernel: 13 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xd]
Mar 16 05:33:11 beam kernel: 68 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x44]
Mar 16 05:33:11 beam kernel: 206 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xce]
Mar 16 05:33:11 beam kernel: 198 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xc6]
Mar 16 05:33:11 beam kernel: 152 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x98]
Mar 16 05:33:11 beam kernel: 40 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x28]
Mar 16 05:33:11 beam kernel: 50 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x32]
Mar 16 05:33:11 beam kernel: 205 SCB_CONTROL[0x64] SCB_SCSIID[0x7] SCB_TAG[0xcd]
Mar 16 05:33:11 beam kernel: 142 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x8e]
Mar 16 05:33:11 beam kernel: 188 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0xbc]
Mar 16 05:33:11 beam kernel: 18 SCB_CONTROL[0x60] SCB_SCSIID[0x37] SCB_TAG[0x12]
Mar 16 05:33:11 beam kernel: Total 49
Mar 16 05:33:11 beam kernel: Kernel Free SCB list: 70 5 153 27 101 64 214 121 195 73 113 164 140 184
63 120 192 163 190 127 30 41 180 171 143 218 14 128 46 35 179 156 197 147 118 4 108 204 31 45 130
125 183 7 72 139 58 42 44 48 178 209 202 67 114 62 194 175 129 71 29 111 39 177 200 191 126 100 104
26 33 157 36 189 78 93 141 9 43 145 207 22 150 1 19 222 86 69 59 105 165 8 149 119 11 107 132 208 2
217 57 54 131 116 51 211 135 172 144 221 61 76 159 109 193 74 148 115 75 151 84 52 88 210 53 25 124
223 47 123 186 181 185 187 83 90 80 182 77 81 176 87 173 95 91 174 82 170 94 168 97 92 169 98 160 99
96 161 102 34 103 158 28 37 0 220 17 23 20 239 232 233 234 235 228 229 230 231 224 225 226 227 49 24
60 3 21 122 238 237 236
Mar 16 05:33:11 beam kernel: Sequencer Complete DMA-inprog list:
Mar 16 05:33:11 beam kernel: Sequencer Complete list:
Mar 16 05:33:11 beam kernel: Sequencer DMA-Up and Complete list:
Mar 16 05:33:11 beam kernel:
Mar 16 05:33:11 beam kernel: scsi0: FIFO0 Active, LONGJMP == 0x8283, SCB 0xbc, LJSCB 0x8c
Mar 16 05:33:11 beam kernel: SEQIMODE[0x3f] SEQINTSRC[0x10] DFCNTRL[0x4] DFSTATUS[0x89]
Mar 16 05:33:11 beam kernel: SG_CACHE_SHADOW[0x2] SG_STATE[0x0] DFFSXFRCTL[0x0]
Mar 16 05:33:11 beam kernel: SOFFCNT[0x3f] MDFFSTAT[0x2] SHADDR = 0x00, SHCNT = 0x0
Mar 16 05:33:11 beam kernel: HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]
Mar 16 05:33:11 beam kernel: scsi0: FIFO1 Active, LONGJMP == 0x25c, SCB 0x12, LJSCB 0x12
Mar 16 05:33:11 beam kernel: SEQIMODE[0x3f] SEQINTSRC[0x40] DFCNTRL[0xc] DFSTATUS[0x89]
Mar 16 05:33:11 beam kernel: SG_CACHE_SHADOW[0x23] SG_STATE[0x0] DFFSXFRCTL[0x0]
Mar 16 05:33:11 beam kernel: SOFFCNT[0x3f] MDFFSTAT[0x16] SHADDR = 0x02b85c000, SHCNT = 0x0
Mar 16 05:33:11 beam kernel: HADDR = 0x02b85c000, HCNT = 0x0 CCSGCTL[0x0]
Mar 16 05:33:11 beam kernel: LQIN: 0x5 0x0 0x0 0xbc 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x20 0x0
0x0 0x0 0x2 0x0
Mar 16 05:33:11 beam kernel: scsi0: LQISTATE = 0x25, LQOSTATE = 0x0, OPTIONMODE = 0x42
Mar 16 05:33:11 beam kernel: scsi0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1
Mar 16 05:33:11 beam kernel: SIMODE0[0xc]
Mar 16 05:33:11 beam kernel: CCSCBCTL[0x0]
Mar 16 05:33:11 beam kernel: scsi0: REG0 == 0x60, SINDEX = 0x122, DINDEX = 0x108
Mar 16 05:33:11 beam kernel: scsi0: SCBPTR == 0x12, SCB_NEXT == 0xffc0, SCB_NEXT2 == 0xfffc
Mar 16 05:33:11 beam kernel: CDB 2a 0 0 80 20 e8
Mar 16 05:33:11 beam kernel: STACK: 0x2e 0x10 0x2e 0x10 0x1 0x25c 0x28f 0x255
Mar 16 05:33:11 beam kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
Mar 16 05:33:11 beam kernel: DevQ(0:0:0): 0 waiting
Mar 16 05:33:11 beam kernel: DevQ(0:1:0): 0 waiting
Mar 16 05:33:11 beam kernel: DevQ(0:2:0): 0 waiting
Mar 16 05:33:11 beam kernel: DevQ(0:3:0): 0 waiting
Mar 16 05:37:55 beam kernel: kjournald starting. Commit interval 5 seconds
Mar 16 05:37:55 beam kernel: EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,55), internal journal
Mar 16 05:37:55 beam kernel: EXT3-fs: mounted filesystem with ordered data mode.
Mar 16 05:47:40 beam kernel: kjournald starting. Commit interval 5 seconds
Mar 16 05:47:40 beam kernel: EXT3 FS 2.4-0.9.18, 14 May 2002 on sd(8,50), internal journal
Mar 16 05:47:40 beam kernel: EXT3-fs: mounted filesystem with ordered data mode.
Justin T. Gibbs wrote:
>>1. Would it be possible for you to look at the error message to see
>>what it is related to.
>
>
> The drive has unexpectedly dropped off the bus during a connection.
> Without a SCSI bus trace it is impossible to know why the drive might
> have done this or if perhaps a glitch on the BSY line is causing the
> controller to detect a spurious busfree.
>
>
>>2. Would it be possible to determine what may have locked up the drive
>>with the previous SCSI driver. I could feed this back to Seagate.
>
>
> I have my hands too full trying to replicate problems seen with the
> latest driver and debug their cause to go back and try and figure
> out what an old driver version might have done to upset a drive.
>
> --
> Justin
>
--
Dr Terry Barnaby BEAM Ltd
Phone: +44 1454 324512 Northavon Business Center, Dean Rd
Fax: +44 1454 313172 Yate, Bristol, BS37 5NH, UK
Email: [email protected] Web: http://www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
"Tandems are twice the fun !"