- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- decoding SCSI driver error messages
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-19-2002 04:07 PM - last edited on тАО06-02-2014 09:34 PM by Maiko-I
тАО11-19-2002 04:07 PM - last edited on тАО06-02-2014 09:34 PM by Maiko-I
decoding SCSI driver error messages
are there any documents that describe how
to decode console (dmesg) logs for
the Symbios-based SCSI adapters?
In particular, to determine which specific target
device is having a problem?
E.g., from the following:
SCSI: Request Timeout -- lbolt: 34294280, dev: cb0f6042
What exactly does "dev" map to? Is
the target device (and logical unit number)
encoded in this record?
Thanks!
P.S. This thread has been moved from Disk to HP-UX > sysadmin. - Hp Forum moderator
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2002 04:48 AM
тАО11-20-2002 04:48 AM
Re: decoding SCSI driver error messages
I think what you can do is note down the string after "cb" in the dev: field of the "Request Timeout" error above.
You can then get the corrsponding device name by doing a:
ll /dev/dsk |grep #string
(or /dev/rmt, depending on if it is a disk or tape device).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-20-2002 06:28 AM
тАО11-20-2002 06:28 AM
Re: decoding SCSI driver error messages
cb 0f 6 0 42
__ __ _ _ __
| | | | |
major# | target | flags
| |
bus# lun
Using this information:
- major# (cb) is 203 in decimal which, I think, maps to device type `sdisk`.
- bus# (0f) is the card instance number (15 in decimal) to which the device is attached.
- target (6) is the device's scsi id.
- lun (0) is the device's logical unit number.
Therefore, this device maps to /dev/dsk/c15t6d0 - would that make sense with your system?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО12-02-2002 01:01 PM
тАО12-02-2002 01:01 PM
Re: decoding SCSI driver error messages
directly, so I'm replying to my base message...)
from what I can see the major code of 203 refers to
the SCSI host adapter controller, itself (which is located
at SCSI ID#7), which does have an instance for #15.
there is a tape device connected at SCSI ID#6
so it looks like the message is telling me that there was
a problem with the library at SCSI-ID#6
connected to controller#15, and
that the error message originated with the controller as opposed
to the library (or I would have seen major number 205).
in any case, our sys-admin is going to see whether that
particular device is giving the library fits
at least we're on the right track, now...
==
tom