Re: Constant mysterious SCSI errors
Dan Nelson writes: Try lowering the max tags for that drive: camcontrol tags da0 -N 32. Tried it. I still get the same error; it doesn't seem to have diminished. I get the queue full stuff in bursts, then the process trying to do the I/O stalls, then after 30-40 seconds I get one of those huge panel dumps I posted, then the process continues. There doesn't seem to be any data loss. The rest of the system continues to run (it's a 2-processor system, so I don't know if one of the processors is halted when this happens). The problem only seems to arise when there is heavy disk activity. If that works, you can stick it in rc.local, or add an entry to the xpt_quirk_table[] in /sys/cam/cam_xpt.c . It probably needs something similar to the quantum quirk lines. The change to cam_spt.c requires a rebuild of the kernel, right? I found references to SCSI quirks on the Net, but not knowing much about SCSI, I wasn't sure which might apply to my situation. Can you explain what all these messages are actually saying? What does it all mean? I never know what to look for in this output, but most of the time, I think it's a cabling or termination problem. Reseat all the plugs :) Well, there haven't been any cabling or termination problems in the past eight years, so it seems unlikely that they've appeared today. I think I can safely rule out any type of actual hardware problem. It's either a software configuration problem or a software bug (which might mean a quirk, I suppose). (Note also that these two drives and the controller are on the internal connector of the controller, and although the controller provides an external connector, too, there's nothing connected to it--which further makes cabling or termination problems unlikely.) -- Anthony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Constant mysterious SCSI errors
I get constant streams of messages concerning my disks on the console whenever I have a lot of disk activity on my system (2x SCSI disks, no IDE or other disks). I'd very much like to know what's going on (there's nothing wrong with the hardware, so either it's a configuration problem, or it's a bug). There doesn't seem to be any data loss or corruption occurring. I've had one or two panics, though (which may or may not have caused data loss--it's hard to tell). While recompiling the kernel, the system stalled periodically (at least anything involving disk I/O stalled) and generated several hundred kilobytes of messages looking like this: Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): Retrying Command Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): Request Requeued Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): Retrying Command Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): Queue Full Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): tagged openings now 64 Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): Retrying Command Feb 26 20:09:24 contactdish kernel: (da0:ahc0:0:0:0): Queue Full Feb 26 20:09:24 contactdish kernel: (da0:ahc0:0:0:0): tagged openings now 63 Feb 26 20:09:24 contactdish kernel: (da0:ahc0:0:0:0): Retrying Command Feb 26 20:09:26 contactdish kernel: (da1:ahc0:0:2:0): Request Requeued Feb 26 20:09:26 contactdish kernel: (da1:ahc0:0:2:0): Retrying Command Feb 26 20:09:26 contactdish kernel: (da1:ahc0:0:2:0): Queue Full Feb 26 20:09:26 contactdish kernel: (da1:ahc0:0:2:0): Retrying Command In addition, I sometimes get bursts of much longer messages, looking something like this: Feb 25 20:09:29 contactdish kernel: ahc0: Recovery Initiated Feb 25 20:09:29 contactdish kernel: Dump Card State Begins Feb 25 20:09:29 contactdish kernel: ahc0: Dumping Card State in Message-in phase, at SEQADDR 0x162 Feb 25 20:09:29 contactdish kernel: Card was paused Feb 25 20:09:29 contactdish kernel: ACCUM = 0xcb, SINDEX = 0x0, DINDEX = 0x88, ARG_2 = 0x0 Feb 25 20:09:29 contactdish kernel: HCNT = 0x0 SCBPTR = 0xa Feb 25 20:09:29 contactdish kernel: SCSISIGI[0xe6]:(REQI|BSYI|MSGI|IOI|CDI) ERROR[0x0] Feb 25 20:09:29 contactdish kernel: SCSIBUSL[0x0] LASTPHASE[0xe0]:(MSGI|IOI|CDI) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) Feb 25 20:09:29 contactdish kernel: SBLKCTL[0x0] SCSIRATE[0xf]:(SXFR_ULTRA2) SEQCTL[0x10]:(FASTMODE) Feb 25 20:09:29 contactdish kernel: SEQ_FLAGS[0x0] SSTAT0[0x7]:(DMADONE|SPIORDY|SDONE) Feb 25 20:09:29 contactdish kernel: SSTAT1[0x3]:(REQINIT|PHASECHG) SSTAT2[0x0] SSTAT3[0x0] Feb 25 20:09:29 contactdish kernel: SIMODE0[0x0] SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) Feb 25 20:09:29 contactdish kernel: SXFRCTL0[0xa8]:(SPIOEN|FAST20|DFON) DFCNTRL[0x0] DFSTATUS[0x29]:(FIFOEMP|HDONE|FIFOQWDEMP) Feb 25 20:09:29 contactdish kernel: STACK: 0x105 0x100 0xe5 0x163 Feb 25 20:09:29 contactdish kernel: SCB count = 100 Feb 25 20:09:29 contactdish kernel: Kernel NEXTQSCB = 19 Feb 25 20:09:29 contactdish kernel: Card NEXTQSCB = 25 Feb 25 20:09:29 contactdish kernel: QINFIFO entries: 25 71 31 Feb 25 20:09:29 contactdish kernel: Waiting Queue entries: Feb 25 20:09:29 contactdish kernel: Disconnected Queue entries: 0:72 1:68 2:84 14:60 12:61 5:53 Feb 25 20:09:29 contactdish kernel: QOUTFIFO entries: Feb 25 20:09:29 contactdish kernel: Sequencer Free SCB List: 10 6 9 3 7 4 13 11 15 8 Feb 25 20:09:29 contactdish kernel: Sequencer SCB Info: Feb 25 20:09:29 contactdish kernel: 0 SCB_CONTROL[0x6c]:(DISCONNECTED|ULTRAENB|TAG_ENB|DISCENB) Feb 25 20:09:29 contactdish kernel: SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0x48] Feb 25 20:09:29 contactdish kernel: 1 SCB_CONTROL[0x6c]:(DISCONNECTED|ULTRAENB|TAG_ENB|DISCENB) Feb 25 20:09:29 contactdish kernel: SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0x44] Feb 25 20:09:29 contactdish kernel: 2 SCB_CONTROL[0x6c]:(DISCONNECTED|ULTRAENB|TAG_ENB|DISCENB) Feb 25 20:09:29 contactdish kernel: SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0x54] Feb 25 20:09:29 contactdish kernel: 3 SCB_CONTROL[0xe8]:(ULTRAENB|TAG_ENB|DISCENB|TARGET_SCB) Feb 25 20:09:29 contactdish kernel: SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0xff] Feb 25 20:09:29 contactdish kernel: 4 SCB_CONTROL[0xe8]:(ULTRAENB|TAG_ENB|DISCENB|TARGET_SCB) Feb 25 20:09:29 contactdish kernel: SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0xff] Feb 25 20:09:29 contactdish kernel: 5 SCB_CONTROL[0x6c]:(DISCONNECTED|ULTRAENB|TAG_ENB|DISCENB) Feb 25 20:09:29 contactdish kernel: SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0x35] Feb 25 20:09:29 contactdish kernel: 6 SCB_CONTROL[0xe8]:(ULTRAENB|TAG_ENB|DISCENB|TARGET_SCB) Feb 25 20:09:29 contactdish kernel: SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0xff] Feb 25 20:09:29 contactdish kernel: 7 SCB_CONTROL[0xe8]:(ULTRAENB|TAG_ENB|DISCENB|TARGET_SCB) Feb 25 20:09:29 contactdish kernel: SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0xff] Feb 25 20:09:29 contactdish kernel: 8 SCB_CONTROL[0xe8]:(ULTRAENB|TAG_ENB|DISCENB|TARGET_SCB) Feb 25
Re: Constant mysterious SCSI errors
In the last episode (Feb 26), Anthony Atkielski said: I get constant streams of messages concerning my disks on the console whenever I have a lot of disk activity on my system (2x SCSI disks, no IDE or other disks). I'd very much like to know what's going on (there's nothing wrong with the hardware, so either it's a configuration problem, or it's a bug). There doesn't seem to be any data loss or corruption occurring. I've had one or two panics, though (which may or may not have caused data loss--it's hard to tell). While recompiling the kernel, the system stalled periodically (at least anything involving disk I/O stalled) and generated several hundred kilobytes of messages looking like this: Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): Queue Full Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): tagged openings now 64 Feb 26 20:09:23 contactdish kernel: (da0:ahc0:0:0:0): Retrying Command Try lowering the max tags for that drive: camcontrol tags da0 -N 32. If that works, you can stick it in rc.local, or add an entry to the xpt_quirk_table[] in /sys/cam/cam_xpt.c . It probably needs something similar to the quantum quirk lines. In addition, I sometimes get bursts of much longer messages, looking something like this: Feb 25 20:09:29 contactdish kernel: ahc0: Recovery Initiated Feb 25 20:09:29 contactdish kernel: Dump Card State Begins Feb 25 20:09:29 contactdish kernel: Dump Card State Ends Feb 25 20:09:29 contactdish kernel: (da1:ahc0:0:2:0): SCB 0x49 - timed out Feb 25 20:09:29 contactdish kernel: sg[0] - Addr 0x1309b000 : Length 2048 Feb 25 20:09:29 contactdish kernel: (da1:ahc0:0:2:0): Queuing a BDR SCB Feb 25 20:09:29 contactdish kernel: ahc0: Timedout SCBs already complete. Interrupts may not be functioning. I never know what to look for in this output, but most of the time, I think it's a cabling or termination problem. Reseat all the plugs :) -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI errors with Adaptec 2200S RAID
On Tue, 03-Aug-2004 at 23:31:52 -0400, [EMAIL PROTECTED] wrote: Please cc replies directly to me, as I am not subscribed to the lists. With some help from here, I was able to get this RAID card to see our external DLT (QUANTUM 4000) SCSI tape drive by installing the aacp (pass through) driver in addition to the aac driver. camcontrol now works, as do basic mt commands and amcheck (amanda check). However, (amanda) dumps either hang, fail completely or fail after transfering very little data. On the console, I see: (sa0:aacp1:0:4:0): READ(06). CDB8 0 0 0 20 0 0 (sa0:aacp1:0:4:0): NO SENSE ILI (length mismatch): -24576 csi:0,0,0,1 At this point the device is completely unresponsive, and the only way to get the system to see it again is to reboot the whole server. I tried ordering a 3 ft cable, thinking I was pushing my luck with the 6 ft (I've had this problem with SCSI cables in the past), but the problem persists. The same drive (which has an active terminator) has been working fine for years on a different box using an Intel L440GX+ MB's on-board SCSI port. Once again, any helpful replies are greatly appreciated! Are you sure you are running a recent fw on your DLT4k? My DLTs used to behave badly with early fw revisions. Check out http://www.quantum.com/am/service_support/downloads/software/dlt4000.htm You can upgrade it by tape or use my software for updating the fw of SCSI devices on FreeBSD. -Andre James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to [EMAIL PROTECTED] -- Regression testing? What's that? If it compiles, it is good, if it boots up, it is perfect. - Linus Torvalds ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCSI errors with Adaptec 2200S RAID
Andre Albsmeier wrote: On Tue, 03-Aug-2004 at 23:31:52 -0400, [EMAIL PROTECTED] wrote: Please cc replies directly to me, as I am not subscribed to the lists. With some help from here, I was able to get this RAID card to see our external DLT (QUANTUM 4000) SCSI tape drive by installing the aacp (pass through) driver in addition to the aac driver. camcontrol now works, as do basic mt commands and amcheck (amanda check). However, (amanda) dumps either hang, fail completely or fail after transfering very little data. On the console, I see: (sa0:aacp1:0:4:0): READ(06). CDB8 0 0 0 20 0 0 (sa0:aacp1:0:4:0): NO SENSE ILI (length mismatch): -24576 csi:0,0,0,1 At this point the device is completely unresponsive, and the only way to get the system to see it again is to reboot the whole server. I tried ordering a 3 ft cable, thinking I was pushing my luck with the 6 ft (I've had this problem with SCSI cables in the past), but the problem persists. The same drive (which has an active terminator) has been working fine for years on a different box using an Intel L440GX+ MB's on-board SCSI port. Once again, any helpful replies are greatly appreciated! Are you sure you are running a recent fw on your DLT4k? My DLTs used to behave badly with early fw revisions. Check out http://www.quantum.com/am/service_support/downloads/software/dlt4000.htm You can upgrade it by tape or use my software for updating the fw of SCSI devices on FreeBSD. -Andre This sounds like excellent advice. Note that the error messages that you are seeing are coming from the Adaptec firmware, not FreeBSD or the aac driver. Also, the aacp device and backing firmware support are really just hacks that exist to allow cdroms to be booted and drives to be flashed with new firmware. I've never heard of anyone running a tape drive in this fashion, so it will be quite interesting to see if newer firmware helps. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
SCSI errors with Adaptec 2200S RAID
Please cc replies directly to me, as I am not subscribed to the lists. With some help from here, I was able to get this RAID card to see our external DLT (QUANTUM 4000) SCSI tape drive by installing the aacp (pass through) driver in addition to the aac driver. camcontrol now works, as do basic mt commands and amcheck (amanda check). However, (amanda) dumps either hang, fail completely or fail after transfering very little data. On the console, I see: (sa0:aacp1:0:4:0): READ(06). CDB8 0 0 0 20 0 0 (sa0:aacp1:0:4:0): NO SENSE ILI (length mismatch): -24576 csi:0,0,0,1 At this point the device is completely unresponsive, and the only way to get the system to see it again is to reboot the whole server. I tried ordering a 3 ft cable, thinking I was pushing my luck with the 6 ft (I've had this problem with SCSI cables in the past), but the problem persists. The same drive (which has an active terminator) has been working fine for years on a different box using an Intel L440GX+ MB's on-board SCSI port. Once again, any helpful replies are greatly appreciated! James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
scsi errors on orb drive
in the search for reliable high density backup media... I chose to use orb drives a couple years ago. 2.2 gis on a direct access device seemed good. Now that one failed completely and another seems troublesome, I'm beginning to understand why they are out of business. below is a kernel message that was thrown when I attempted to umount the orb drive. Can anyone tell me what it means? (da2:ahc0:0:5:0): SCB 0x72 - timed out ahc0: Dumping Card State while idle, at SEQADDR 0x9 ACCUM = 0x0, SINDEX = 0x2f, DINDEX = 0xe4, ARG_2 = 0x20 HCNT = 0x0 SCSISEQ = 0x12, SBLKCTL = 0x6 DFCNTRL = 0x0, DFSTATUS = 0x89 LASTPHASE = 0x1, SCSISIGI = 0x0, SXFRCTL0 = 0x80 SSTAT0 = 0x0, SSTAT1 = 0x8 SCSIPHASE = 0x0 STACK == 0x3, 0x108, 0x160, 0x0 SCB count = 140 Kernel NEXTQSCB = 90 Card NEXTQSCB = 90 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: 30:114 QOUTFIFO entries: Sequencer Free SCB List: 12 17 6 7 24 4 27 29 22 3 10 21 18 20 19 16 14 13 0 31 5 26 11 8 1 15 25 23 2 28 9 Pending list: 114 Kernel Free SCB list: 47 10 85 95 31 124 111 105 56 55 119 94 117 12 23 93 30 18 49 3 59 84 73 20 75 34 64 43 118 27 42 40 70 89 8 101 26 113 97 17 24 48 19 32 61 16 91 35 45 13 22 87 69 106 46 139 107 74 127 29 66 112 50 78 21 129 1 28 2 115 77 72 36 71 83 128 51 25 125 57 96 9 11 109 88 53 60 62 7 116 0 80 41 68 92 79 102 5 58 108 52 81 15 103 76 110 82 98 37 39 104 6 4 54 44 63 86 65 99 33 126 100 67 38 123 122 121 120 14 138 137 136 135 134 133 132 131 130 Untagged Q(5): 114 sg[0] - Addr 0xe1bc000 : Length 2048 (da2:ahc0:0:5:0): Queuing a BDR SCB (da2:ahc0:0:5:0): Bus Device Reset Message Sent (da2:ahc0:0:5:0): SCB 0x72 - timed out ahc0: Dumping Card State in Message-out phase, at SEQADDR 0x168 ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0xe4, ARG_2 = 0x1c HCNT = 0x0 SCSISEQ = 0x12, SBLKCTL = 0x6 DFCNTRL = 0x0, DFSTATUS = 0x89 LASTPHASE = 0xa0, SCSISIGI = 0xa4, SXFRCTL0 = 0x88 SSTAT0 = 0x0, SSTAT1 = 0x0 SCSIPHASE = 0x0 STACK == 0x175, 0x160, 0x0, 0xe7 SCB count = 140 Kernel NEXTQSCB = 90 Card NEXTQSCB = 90 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: QOUTFIFO entries: Sequencer Free SCB List: 12 17 6 7 24 4 27 29 22 3 10 21 18 20 19 16 14 13 0 31 5 26 11 8 1 15 25 23 2 28 9 Pending list: 114 Kernel Free SCB list: 47 10 85 95 31 124 111 105 56 55 119 94 117 12 23 93 30 18 49 3 59 84 73 20 75 34 64 43 118 27 42 40 70 89 8 101 26 113 97 17 24 48 19 32 61 16 91 35 45 13 22 87 69 106 46 139 107 74 127 29 66 112 50 78 21 129 1 28 2 115 77 72 36 71 83 128 51 25 125 57 96 9 11 109 88 53 60 62 7 116 0 80 41 68 92 79 102 5 58 108 52 81 15 103 76 110 82 98 37 39 104 6 4 54 44 63 86 65 99 33 126 100 67 38 123 122 121 120 14 138 137 136 135 134 133 132 131 130 Untagged Q(5): 114 sg[0] - Addr 0xe1bc000 : Length 2048 (da2:ahc0:0:5:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 1 SCBs aborted (da2:ahc0:0:5:0): Invalidating pack - End forwarded message - -- David Bear phone: 480-965-8257 fax:480-965-9189 College of Public Programs/ASU Wilson Hall 232 Tempe, AZ 85287-0803 Beware the IP portfolio, everyone will be suspect of trespassing ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
SCSI errors.
Hi there! I need a help to investigate a problem with my SCIS disks or cards. Can someone tell me please what doest this error indicate? Jun 25 13:53:22 prioris /kernel: (da3:ahc0:0:5:0): SCB 0x15 - timed out Jun 25 13:53:22 prioris /kernel: Dump Card State Begins Jun 25 13:53:22 prioris /kernel: ahc0: Dumping Card State while idle, at SEQADDR 0x7 Jun 25 13:53:22 prioris /kernel: Card was paused Jun 25 13:53:22 prioris /kernel: ACCUM = 0xc3, SINDEX = 0x50, DINDEX = 0x8c, ARG_2 = 0x0 Jun 25 13:53:22 prioris /kernel: HCNT = 0x0 SCBPTR = 0x2 Jun 25 13:53:22 prioris /kernel: SCSISIGI[0x0] ERROR[0x0] SCSIBUSL[0x0] LASTPHASE[0x1] Jun 25 13:53:22 prioris /kernel: SCSISEQ[0x12] SBLKCTL[0x0] SCSIRATE[0x0] SEQCTL[0x10] Jun 25 13:53:22 prioris /kernel: SEQ_FLAGS[0xc0] SSTAT0[0x5] SSTAT1[0xa] SSTAT2[0x0] Jun 25 13:53:22 prioris /kernel: SSTAT3[0x0] SIMODE0[0x0] SIMODE1[0xa4] SXFRCTL0[0x80] Jun 25 13:53:22 prioris /kernel: DFCNTRL[0x0] DFSTATUS[0x29] Jun 25 13:53:22 prioris /kernel: STACK: 0x0 0x162 0x105 0x3 Jun 25 13:53:22 prioris /kernel: SCB count = 120 Jun 25 13:53:22 prioris /kernel: Kernel NEXTQSCB = 24 Jun 25 13:53:22 prioris /kernel: Card NEXTQSCB = 24 Jun 25 13:53:22 prioris /kernel: QINFIFO entries: Jun 25 13:53:22 prioris /kernel: Waiting Queue entries: Jun 25 13:53:22 prioris /kernel: Disconnected Queue entries: 10:21 Jun 25 13:53:22 prioris /kernel: QOUTFIFO entries: Jun 25 13:53:22 prioris /kernel: Sequencer Free SCB List: 2 12 9 14 0 6 3 5 4 13 15 7 8 11 1 Jun 25 13:53:22 prioris /kernel: Sequencer SCB Info: Jun 25 13:53:22 prioris /kernel: 0 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:22 prioris /kernel: 1 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:22 prioris /kernel: 2 SCB_CONTROL[0xe0] SCB_SCSIID[0x27] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:22 prioris /kernel: 3 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:22 prioris /kernel: 4 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:22 prioris /kernel: 5 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:22 prioris /kernel: 6 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:22 prioris /kernel: 7 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:22 prioris /kernel: 8 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:22 prioris /kernel: 9 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:23 prioris /kernel: 10 SCB_CONTROL[0x64] SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x15] Jun 25 13:53:23 prioris /kernel: 11 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:23 prioris /kernel: 12 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:23 prioris /kernel: 13 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:23 prioris /kernel: 14 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:23 prioris /kernel: 15 SCB_CONTROL[0xe0] SCB_SCSIID[0x17] SCB_LUN[0x0] SCB_TAG[0xff] Jun 25 13:53:23 prioris /kernel: Pending list: Jun 25 13:53:23 prioris /kernel: 21 SCB_CONTROL[0x60] SCB_SCSIID[0x57] SCB_LUN[0x0] Jun 25 13:53:23 prioris /kernel: Kernel Free SCB list: 80 100 105 117 113 42 55 85 33 91 57 27 59 94 22 45 46 96 106 6 14 16 52 82 18 54 66 7 51 116 99 69 9 115 107 118 0 20 15 111 65 28 30 17 103 47 34 97 36 10 108 53 8 19 119 40 44 2 112 32 50 98 39 92 5 114 102 11 12 13 3 49 38 68 41 95 56 67 37 84 23 109 26 81 110 4 58 90 93 25 101 104 31 29 48 83 43 1 35 86 87 88 89 70 71 72 73 74 75 76 77 78 79 60 61 62 63 64 Jun 25 13:53:23 prioris /kernel: Jun 25 13:53:23 prioris /kernel: Dump Card State Ends Jun 25 13:53:23 prioris /kernel: sg[0] - Addr 0x6c3b000 : Length 4096 Jun 25 13:53:23 prioris /kernel: sg[1] - Addr 0xb67c000 : Length 2048 Jun 25 13:53:23 prioris /kernel: (da3:ahc0:0:5:0): Queuing a BDR SCB Jun 25 13:53:23 prioris /kernel: (da3:ahc0:0:5:0): Bus Device Reset Message Sent Jun 25 13:53:23 prioris /kernel: (da3:ahc0:0:5:0): no longer in timeout, status = 34b Jun 25 13:53:23 prioris /kernel: ahc0: Bus Device Reset on A:5. 1 SCBs aborted Jun 25 13:53:23 prioris /kernel: Jun 25 13:53:23 prioris /kernel: Dump Card State Ends Jun 25 14:33:40 prioris /kernel: (da3:ahc0:0:5:0): Unexpected busfree in Data-out phase Jun 25 14:33:40 prioris /kernel: SEQADDR == 0x7a Jun 25 14:38:49 prioris /kernel: SEQADDR == 0x7a Jun 25 14:38:49 prioris /kernel: (da3:ahc0:0:5:0): SCB 0x69 - timed out It hapens to one of the HD only. Can anyone point me to a good direction please? Thanks, gregory -- Grzegorz Czaplinski gregory at prioris.mini.pw.edu.pl The Power to Serve, Right for the Power Users! - http://www.FreeBSD.org/ Fingerprint: EB77 E19D CFA2 5736 810F 847C A70F A275 2489 469F pgp0.pgp Description: PGP signature
