| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1959.1 | | SMURF::KNIGHT | Fred Knight | Wed Mar 19 1997 13:02 | 7 |
| That problem did not effect system functionality. But since
it was ugly (customers prefer empty error log files), the
problem was fixed. I suppose an IPMT could get you a patch
if you want to try. On the other hand, you might just get
the answer - "just ignore it - it doesn't effect anything."
Fred
|
| 1959.2 | thanks! | ATZIS2::PUTZENLECHNE | wherever is fun, there's always ALPHA | Thu Mar 20 1997 07:20 | 1 |
|
|
| 1959.3 | Patched on what version? | VIRGIN::SUTTER | Who are you ??? - I'm BATMAN !!! | Wed Mar 26 1997 08:30 | 134 |
| Hi Fred,
we have a Digital UNIX V4.0B/TruCluster V1.4 installation and
see these errors as well. When/where was/is this problem fixed?
Regards,
Arnold
# uname -a
OSF1 swissair V4.0 564 alpha
# dia -R
******************************** ENTRY 9 ********************************
Logging OS 2. Digital UNIX
System Architecture 2. Alpha
Event sequence number 131.
Timestamp of occurrence 26-MAR-1997 14:10:42
Host name swissair
System type register x00000018 AlphaServer 2000A or 2100A
Number of CPUs (mpnum) x00000001
CPU logging event (mperr) x00000000
Event validity 1. O/S claims event is valid
Event severity 5. Low Priority
Entry type 199. CAM SCSI Event Type
------- Unit Info -------
Bus Number 0.
Unit Number x0000 Target = 0.
LUN = 0.
------- CAM Data -------
Class x1F Unknown Class
Subsystem x1F Unknown Subsystem
Number of Packets 6.
------ Packet Type ------ 258. Module Name String
Routine Name SCSI_reserve
------ Packet Type ------ 256. Generic String
Unit Attention received
------ Packet Type ------ 261. Soft Error String
Error Type Soft Error Detected (recovered)
------ Packet Type ------ 256. Generic String
Active CCB at time of error
------ Packet Type ------ 1. SCSI I/O Request CCB(CCB_SCSIIO)
Packet Revision 76.
CCB Address xFFFFFC000FF13E80
CCB Length x00C0
XPT Function Code x01 Execute requested SCSI I/O
Cam Status x84 CCB Request Completed WITH Error
Autosense Data Valid for Target
Path ID 1.
Target ID 1.
Target LUN 0.
Cam Flags x000044C0 Data Direction (11: no data)
Disable the SIM Queue Frozen State
Attempt Sync Data Xfer - SDTR
*pdrv_ptr xFFFFFC000FF13B28
*next_ccb x0000000000000000
*req_map x0000000000000000
void (*cam_cbfcnp)() xFFFFFC00002C46B8
*data_ptr x0000000000000000
Data Transfer Length 0.
*sense_ptr xFFFFFC000FF13B50
Auotsense Byte Length 164.
CDB Length 6.
Scatter/Gather Entry Cnt 0.
SCSI Status x02 Check Condition
Autosense Residue Length x92
Transfer Residue Length x00000000
(CDB) Command & Data Buf
15--<-12 11--<-08 07--<-04 03--<-00 :Byte Order
0000: 00000000 00000000 00000016 * ............*
Timeout Value x00000006
*msg_ptr x0000000000000000
Message Length 0.
Vendor Unique Flags x0000
Tag Queue Actions x00
------ Packet Type ------ 768. SCSI Sense Data
Packet Revision 0.
Error Code x70 Current Error
Segment # x00
Information Byte 3 x00
Byte 2 x00
Byte 1 x00
Byte 0 x00
Sense Key x06 Unit Attention
Additional Sense Length x0A
CMD Specific Info Byte 3 x00
Byte 2 x00
Byte 1 x00
Byte 0 x00
ASC & ASCQ x2900 ASC = x0029
ASCQ = x0000
Power On, Reset, or Bus Device Reset
Occurred
FRU Code x01
Sense Key Specific Byte 0 x00 Sense Key Data NOT Valid
Byte 1 x00
Byte 2 x00
Addition Sense Data Size Allocated by Driver
Count of valid bytes: 150.
15--<-12 11--<-08 07--<-04 03--<-00 :Byte Order
0000: 00000000 00000000 00000000 00000000 *................*
0010: 00000000 00000000 00000000 00000000 *................*
0020: 00000000 00000000 00000000 00000000 *................*
0030: 00000000 00000000 00000000 00000000 *................*
0040: 00000000 00000000 00000000 00000000 *................*
0050: 00000000 00000000 00000000 00000000 *................*
0060: 00000000 00000000 00000000 00000000 *................*
0070: 00000000 00000000 00000000 00000000 *................*
0080: 00000000 00000000 00000000 00000000 *................*
0090: 00000000 7E250000 00000000 00000000 *..........%~<^..*
|
| 1959.4 | | SMURF::KNIGHT | Fred Knight | Tue Apr 01 1997 13:03 | 11 |
| Note, that this error is different than the one mentioned in note .0
This particular event is a normal event. Nothing is wrong, nothing
is broken. After a power on, or reset of any kind, the next access
to the disk will cause the disk to tell the host that it was reset.
In this case, when ASE went to do the reserve (note the module name
is SCSI_reserve), the disk said "I was reset" (ASE/ASCQ of 29/00).
The ASE code then logged the event, and did the reserve again (which
worked - since there was no failure to reserve message logged).
Fred
|
| 1959.5 | Why reset of bus#0/target#0/lun#0 ? | ZUR01::VORBURGER | live and let live | Wed Apr 02 1997 11:39 | 11 |
|
I wonder why it logs a reset of bus#0 target# lun#0 even if there is
no device with target#0 connected to bus#0.
Also bus#0 is not a shared bus.
The same kind of messages in re.-2 will be logged during a relocation of
an ASE-service.
Fran�ois V.
|
| 1959.6 | Yes, a bug; but the information is hidden inside the packet. | SMURF::KNIGHT | Fred Knight | Wed Apr 02 1997 17:50 | 29 |
| You are correct. There is a bug in the logging that causes
the main packet to not get the correct unit # stuff.
However, down in the guts of the packet it says:
Path ID 1.
Target ID 1.
Target LUN 0.
So there data is there, just hard to find. The code that
needs fixing is in am_scsi.c as follows:
CAM_ERROR("SCSI_reserve", "Unit Attention received",
CAM_SOFTERR, (CCB_HEADER *)ccb, NULL,
(u_char *)NULL);
should be changed to:
CAM_ERROR("SCSI_reserve", "Unit Attention received",
CAM_SOFTERR, (CCB_HEADER *)ccb, dev,
(u_char *)NULL);
in both places in the am_scsi.c module (the other is in routine
SCSI_release). It is reasonable that this message might be logged
during a relocation (since one thing that might happen during a
relocation is a device reset - to cause the device to release the
reservation from the "old" node).
Fred
|
| 1959.7 | QAR#52309 | VIRGIN::SUTTER | Who are you ??? - I'm BATMAN !!! | Thu Apr 03 1997 04:17 | 8 |
| This is now QAR#52309 logged against TCR 1.4 so this will
be fixed for TCR 1.5.
Thank's Fred for your investigations!
Regards,
Arnold
|