Scsi errors on V240

Hi friends
My sun server v240 conncted with storage array.
whenever, I run scsi related commands like cfgadm or probescsi to configure something I'm getting plenty of scsi errors....
genunix: [ID 408822 kern.info] NOTICE: glm0: fault detected in device; service still available
scsi: [ID 107833 kern.warning] WARNING: /pci@1c,600000/scsi@2 (glm0):
can you please update me, is there any patches required or which hardware has the exact problem............

This does not appear to be an actual storage issue.
It's likely to be a GLM patch issue.
If that is the only device that produces such error messages,
it could be an issue with a single individual disk drive.
As per Spectrum Infodoc 21216
http://sunsolve.sun.com/handbook_pub/Systems/Example/documents/21216.html
the device path of /pci@1c,600000/scsi@2 for "glm0" is your boot drive.
Bring the system down, remove the disk, and reseat it back into place.
Log into Sunsolve and see if there are any
firmware patches for that brand/model of disk.
Patch updates for the GLM driver are usually a part of the kernel update.
Patch your system with the full Recommended Patch Cluster,
which brings the entire V240's OS up to current capabilities.

Similar Messages

SCSI errors in a Sun/Storagetek environment

Hallo everyone,
i experienced SCSI error messages in the /var/adm/messages file.
The system is composed by a Sun server V240 connected to a StorageTek L700 library through two SCSI cables.
Apparently in a random way i receive some SCSI errors that make it impossible to complete I/O operation on a tape media (IBM LTO2).
Here is a sample of the message detail:
Apr 11 15:12:01 azmvipa scsi: [ID 107833 kern.warning] WARNING: /pci@8,600000/pci@1/scsi@4/st@0,0 (st0):
Apr 11 15:12:01 azmvipa      Error for Command: write file mark Error Level: Fatal
Apr 11 15:12:01 azmvipa scsi: [ID 107833 kern.notice]      Requested Block: 1 Error Block: 1
Apr 11 15:12:01 azmvipa scsi: [ID 107833 kern.notice]      Vendor: IBM Serial Number:
Apr 11 15:12:01 azmvipa scsi: [ID 107833 kern.notice]      Sense Key: Media Error
Apr 11 15:12:01 azmvipa scsi: [ID 107833 kern.notice]      ASC: 0xc (write error), ASCQ: 0x0, FRU: 0x6
Does anyone have any idea about which could be the source for this problem, or if there is any way to know if it is generated by the server or the storage device?
Thank you
-- Andrea

Hi
did you find any solution for this.....
I too have same issue with v240 server hardware, plenty of errors when running cfgadm command ..........
thanks a lot
regd
vijay

SUN Blade 2000 giving FATAL SCSI Error while booting from CDROM

Hi,
SUN Blade 2000 system giving "FATAL SCSI Error at Script address 110 SCSI parity Error Arbitration Complete" while trying to boot from CDROM.
Thanks in advance.
Bye
vijay

Hi,
SUN Blade 2000 system giving "FATAL SCSI Error at Script address 110 SCSI parity Error Arbitration Complete" while trying to boot from CDROM.
Thanks in advance.
Bye
vijay

Fatal SCSI Error

Hello,
I've a problem with my Ultra 10.
"Fatal SCSI error at script address 100 Illegal instruction"
What can i do????
Thanks

Unplug any PCI SCSI adapters you have installed to narrow it down. There is no SCSI in an Ultra 10, by default.

Sles9 sp2 scsi error internal target failure buffer I/O error

Apr 3 10:40:41 hostname kernel: SCSI error : <2 0 0 0> return code = 0x10000
Apr 3 10:40:41 hostname kernel: end_request: I/O error, dev sdb, sector 24047
Apr 3 10:40:41 hostname kernel: Buffer I/O error on device sdb1, logical block 2998
Apr 3 10:40:41 hostname kernel: lost page write due to I/O error on sdb1
can any one tell me what happened ? i had checked the disk
had no medium error. after remount , it goes well. but this will happen again.

961262 wrote:
The used tables:
Table 1: 312 col, 12,248 MB, 11,138,561 rows, avg len 621 bytes
Table 2: 159 col, 4288 MB, 5,441,171 rows, avg len 529 bytes
Table 3: 118 col, 360MB, 820,259 rows, avg len 266 bytes
The FTS has improved as expected. With 5 physical drives in a RAID0, a performance of
420MB/s was achieved.
In the write test on the other hand we were not able to archieve any improvement.
The CTAS statement always works with about 5000 - 6000 BLOCK/s (80MB/s)
But when we tried running several CTAS statements in different sessions, the overall speed increased as expected.
Further tests showed that the write speed seems to depend also on the number of columns. 80MB/s were only
possible with Tables 2 and 3. With Table 1, however only 30MB/s were measured.
If multiple CTAS can produce higher throughput on writes this tells you that it is the production of the data that is the limit, not the writing. Notice in your example that nearly 75% of the time of the CTAS as CPU, not I/O.
The thing about number of columns is that table 1 has exceeded the critical 254 limit - this means Oracle has chained all the rows internally into two pieces; this introduces lots of extra CPU-intensive operations (consistent gets, table access by rowid, heap block compress) so that the CPU time could have gone up significantly, resulting in a lower throughput that you are interpreting as a write problem.
One other thought - if you are currently doing CTAS by "create as select from {real SAP table}" there may be other side effects that you're not going to see. I would do "create test clone of real SAP table", then "create as select from clone" to try and eliminate any such anomalies.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b>

Galaxy and SCSI Error - ASC[0x30], ASCQ[0x00] incompatible medium installed

hello,
Windows 2003
Commvault Galaxy 6.1
Storagetek SL500
PROBLEM:
The cleaning jobs do not work, I get the Galaxy messages:
The SCSI device reported an error while executing the SCSI operation
SCSI Operation: Move Media From Slot To Drive.
SCSI Error - ASC[0x30], ASCQ[0x00] incompatible medium installed
The cleaning tapes and barcodes are LTO3 compatibles
The last firmware and drivers are installed.
Any idea ?
Thanks and regards

hello,
Windows 2003
Commvault Galaxy 6.1
Storagetek SL500
PROBLEM:
The cleaning jobs do not work, I get the Galaxy messages:
The SCSI device reported an error while executing the SCSI operation
SCSI Operation: Move Media From Slot To Drive.
SCSI Error - ASC[0x30], ASCQ[0x00] incompatible medium installed
The cleaning tapes and barcodes are LTO3 compatibles
The last firmware and drivers are installed.
Any idea ?
Thanks and regards

Scsi error with glm driver

Hi All,
I have V240 with onboard LVD SCSI port running Solaris 10 02/08, i connected one LTO tape drive with V240 over LVD SCSI port successfully.
The Tape drive is ok to read/write data to the tapes inserted, but some days ago, there was a warning message issued when writing the data to tape for more minutes
WARNING: /pci@1c,600000/SCSI@2,1 (glm1): Disconnected command timeout for targets 1.1
This error makes the progess of the read/wite tobe corrupted
I looked closely on the driver configuration file /kernel/drv/glm.conf but no this file existed. please show me how to fix this error ?
Thanks
Scott

Hi,
Do you know how to create a glm.conf /kernel/drv with some scsi-options to change timeout ?
Thanks
Scott

SCSI error on new LUN/Zoning layout

I am connecting an array to a SUN V440 and I am seeing these error :
1. fcp: [ID 445167 kern.warning] WARNING: ssfcp_create_pip: fp1: no driver for device @w50001fe15008021d,0:
fcp: [ID 445167 kern.warning] WARNING: ssfcp_create_pip: fp0: no driver for device @w50001fe15007e358,0:
2. scsi: [ID 107833 kern.notice] ASC: 0x25 (LUN not supported), ASCQ: 0x0, FRU: 0x0
3. scsi: [ID 107833 kern.notice] ASC: 0x29 (power on, reset, or bus reset occurred), ASCQ: 0x0, FRU: 0x0
4. scsi: [ID 107833 kern.notice] ASC: 0x3f (reported LUNs data has changed), ASCQ: 0xe, FRU: 0x0
5. mpxio: [ID 669396 kern.info] /scsi_vhci/ssd@g600508b4001081c40000c00002d70000 (ssd55) multipath status: optimal, path /pci@1d,700000/SUNW,qlc@1/fp@0,0 (fp1) to target address: 50001fe15008021d,4 is online. Load balancing: round-robin
Is this just FC-AL loop reset due to bad disk?

Just for interests sake, what did you do just prior to these messages arriving.
Were you making zoning changes in a switch? The reason I asked is that adding or removings LUNS out of a zone will spit out some seriously worrying messages but they should be expected. I know as our operators tend to forget about RFC's and panic when I move Luns around.
Also, what sort of storage are you using? Some non Sun vendors require changes to the scsi_vhci.conf for the system to recognise the storage, especially HP stuff.
Line 5 seems to indicate that the storage in the first line of line 1 is ok and you have multiple paths to the LUN. Not sure about the second line 1 message if that makes sense.
Cheers
Stephen

Scsi error during solaris 8 ia installation

Hi folks,
I try to (re-)install Intel Solaris 8 on my machine and fail getting the error message "Warning: /pci@0,0/pci9005,f@6 (cadp0): timeout: abort request, target=0, lun=0". This varies, sometimes I get "abort device", sometimes "reset bus". Then: "SCSI transport failed, reason: timeout (or reason reset)". Can anyone give me a hint what to do about that?
- I am using an Adaptec 7890 scsi controller. My dealer ensures me that it is not defective and he has successfully installed win95 on it.
- I've been successfully running Solaris 8 on this same machine for quite a while, so hardware is compatible. (Trouble started when I tried to install the recommended patch set. Anything went wrong after that, and nothing short of complete reinstallation would do.)
- I tried webstart installation and interactive installation, same result.
I'd appreciate any help. Thanks in advance!
Bernd.

After all, the hard disk did turn out to be defective inspite of
my dealers protestations. After replacing the disk everything was
fine ...
Not really everything. Something IS wrong with the recommended patch
set (Solaris 8 x86_Recommended Patch Cluster Mar/09/0)! After
installing the patch set my machine refused to boot, and I had to
install the os all over again!

Scsi Errors V880 -- L180

Hi,
I have a V880 server with 2 separate diff cards., and a L180 with 2 tape drives. I have tried various ways to connect them up to get the tape drives / robot recognised. I have installed Veritas Netbackup and am using the scsi passthru driver. The only way that seems to recognise everything gives me the following messages on boot:
Apr 23 11:06:14 bhxsvr005 scsi: WARNING: /pci@9,700000/scsi@4 (glm3):
Apr 23 11:06:14 bhxsvr005 SCSI bus DATA IN phase parity error
Apr 23 11:06:14 bhxsvr005 scsi: WARNING: /pci@9,700000/scsi@4 (glm3):
Apr 23 11:06:14 bhxsvr005 SCSI bus DATA IN phase parity error
Apr 23 11:06:14 bhxsvr005 scsi: WARNING: /pci@9,700000/scsi@4 (glm3):
Apr 23 11:06:14 bhxsvr005 Target 0 reducing sync. transfer rate
Apr 23 11:06:14 bhxsvr005 scsi: WARNING: /pci@9,700000/scsi@4 (glm3):
Apr 23 11:06:14 bhxsvr005 SCSI bus DATA IN phase parity error
Apr 23 11:06:14 bhxsvr005 scsi: WARNING: /pci@9,700000/scsi@4 (glm3):
Apr 23 11:06:14 bhxsvr005 SCSI bus DATA IN phase parity error
Apr 23 11:06:14 bhxsvr005 scsi: WARNING: /pci@9,700000/scsi@4 (glm3):
Apr 23 11:06:14 bhxsvr005 Target 0 disabled wide SCSI mode
Apr 23 11:06:14 bhxsvr005 scsi: WARNING: /pci@9,700000/scsi@4 (glm3):
Apr 23 11:06:14 bhxsvr005 Target 0 reverting to async. mode
Apr 23 11:06:15 bhxsvr005 scsi: WARNING: /pci@8,700000/scsi@3 (glm1):
Apr 23 11:06:15 bhxsvr005 SCSI bus DATA IN phase parity error
Apr 23 11:06:15 bhxsvr005 scsi: WARNING: /pci@8,700000/scsi@3 (glm1):
Apr 23 11:06:15 bhxsvr005 SCSI bus DATA IN phase parity error
Apr 23 11:06:15 bhxsvr005 scsi: WARNING: /pci@8,700000/scsi@3 (glm1):
Apr 23 11:06:15 bhxsvr005 Target 1 reducing sync. transfer rate
Apr 23 11:06:15 bhxsvr005 scsi: WARNING: /pci@8,700000/scsi@3 (glm1):
Apr 23 11:06:15 bhxsvr005 SCSI bus DATA IN phase parity error
Apr 23 11:06:15 bhxsvr005 scsi: WARNING: /pci@8,700000/scsi@3 (glm1):
Apr 23 11:06:15 bhxsvr005 SCSI bus DATA IN phase parity error
Apr 23 11:06:15 bhxsvr005 scsi: WARNING: /pci@8,700000/scsi@3 (glm1):
Apr 23 11:06:15 bhxsvr005 Target 1 disabled wide SCSI mode
Apr 23 11:06:15 bhxsvr005 scsi: WARNING: /pci@8,700000/scsi@3 (glm1):
Apr 23 11:06:15 bhxsvr005 Target 1 reverting to async. mode
I have one cable from server to one tape drive, which is then terminated.
The second cable from the server goes to the robot controller, then daisy-chained to the other tape drive which is then terminated.
Thanks in advance.
Chris.

Chris,
Check your SCSI cables for bent pins etc. Could be a bad cable or termination. Also, check for firmware and patches.

Boot load failed, fatal SCSI error, disk read error, Elf64 read error

Just came from vacation and started the Unix Solaris system from work.
Unfortunately I get these errors that you can see in the image:
Can someone tell me what is the problem? Until now I didn't had this issue before.
Thanks!

Moderator Action:
This thread has been moved from the Solaris Kernel discussion space,
to the Sun Servers HARDWARE discussion space, for closer topic alignment.
I concur with Pascal that you do not have a Solaris kernel issue, nor even a Solaris issue.
You have an ancient AXI systemboard (which was a piece of hardware manufactured by Sun Microsystems for the OEM market -- most likely the SPARCengine CP1500 board). It is UltraSPARC-IIi hardware that is about 15 to 20 years old, and it is tired.
I suggest you shut the box down, completely take it apart and then put it back together again.
Remove all accumulated dust and lint.
Remove and reinstall the CPU modules. Remove and reinstall the RAM. Remove and reinstall all expansion board risers. Remove and reinstall all adapter cards. Examine all internal data cabling. Clean any and all cooling fans as well as the power supply.
That action will burnish all mechanical and electrical connections.
After you have re-assembled the box, boot from CDROM and examine all your filesystems. FSCK any that require it.

SCSI Errors

I am getting the following mesg. in /var/adm/messages. What could be the problem?? (M/C E250, OS - 2.6)
May 27 23:11:09 sun2000 unix: sf0: sf_cmd_callback: Lost Frame (read) received 0x8 expected 0x1f4 target 0x1^M May 27 23:11:09 sun2000 unix: WARNING: /sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w50020f2300008fd0,0 (ssd0):^M^M May 27 23:11:09 sun2000 unix: SCSI transport failed: reason 'incomplete': retrying command^M^M May 27 23:11:09 sun2000 unix: sf0: sf_cmd_callback: Lost Frame (read) received 0x8 expected 0x1f4 target 0x1^M May 27 23:11:10 sun2000 last message repeated 2 times May 27 23:11:10 sun2000 unix: WARNING: /sbus@2,0/SUNW,socal@d,10000/sf@0,0/ssd@w50020f2300008fd0,0 (ssd0):^M^M May 27 23:11:10 sun2000 unix: disk not responding to selection^M^M May 27 23:11:10 sun2000 unix: sf2: sf_cmd_callback: Lost Frame (read) received 0x8 expected 0x1f4 target 0x1^M May 27 23:11:10 sun2000 unix: WARNING: /sbus@6,0/SUNW,socal@d,10000/sf@0,0/ssd@w50020f2300004fb6,0 (ssd1):^M^M May 27 23:11:10 sun2000 unix: SCSI transport failed: reason 'incomplete': retrying command^M^M May 27 23:11:10 sun2000 unix: sf2: sf_cmd_callback: Lost Frame (read) received 0x8 expected 0x1f4 target 0x1^M May 27 23:11:10 sun2000 last message repeated 2 times May 27 23:11:10 sun2000 unix: WARNING: /sbus@6,0/SUNW,socal@d,10000/sf@0,0/ssd@w50020f2300004fb6,0 (ssd1):^M^M May 27 23:11:10 sun2000 unix: disk not responding to selection^M^M May 28 01:48:30 sun2000 unix: NOTICE: msgcnt 58 vxfs: mesg 001: vx_nospace - /dev/vx/dsk/view2dg3/sync-4 file system full (1 block extent)
Thanks Karthik

Hi,
Yeah .. you are right. The system model is Sun Enterprise E6500 and the following is a partial list of prtdiag,
========================= IO Cards =========================
Bus Freq
Brd Type MHz Slot Name Model
1 SBus 25 0 QLGC,isp/sd (block) QLGC,ISP1000U
1 SBus 25 1 SUNW,socal/sf (scsi-3) 501-3060
1 SBus 25 3 SUNW,hme
1 SBus 25 3 SUNW,fas/sd (block)
1 SBus 25 13 SUNW,socal/sf (scsi-3) 501-3060
3 SBus 25 0 QLGC,isp/sd (block) QLGC,ISP1000U
3 SBus 25 1 network SUNW,sbus-gem
3 SBus 25 3 SUNW,hme
3 SBus 25 3 SUNW,fas/sd (block)
3 SBus 25 13 SUNW,socal/sf (scsi-3) 501-3060
No failures found in System
===========================
No System Faults found
======================
Pl. guide me how do I proceed now? How to find the Node WWN numbers of FC adapaters in Solairs and what do I do with them.
Thanks
Karthik S S

V240 scsi problems w/dlt4000

Hi
I have a legacy dlt4000 drive inside a library. When I connect the drive to any of my v240/v210/T1 hosts, SCSI bus fails (orange service light turns on).
dlt is SCSI2-SE, multiple cables and terminators was used, I tried it at Solaris 9, Solaris 10 and Solaris 11
SCSI error comes also with drive disconnected from power and removed from library
Drive is working ok (it comes from technical service and all test was ok), it's a Quantum DLT4000, model TH5XA, and it's supposed to work with Solaris. I change all modifiable jumpers without success.
All my SCSI hba are SE/LVD (dual)
Configuring /kernel/drv/glm.conf with
scsi-options=0x78;
or
scsi-options=0x178;
gives the same problem.
messages are:
Apr 17 16:57:39 pampa scsi: [ID 107833 kern.warning] WARNING: /pci@1c,600000/scsi@2,1 (glm1):
Apr 17 16:57:39 pampa timeout on bus reset interrupt
Apr 17 16:57:39 pampa genunix: [ID 408789 kern.warning] WARNING: glm1: fault detected in device; service unavailable
Apr 17 16:57:39 pampa genunix: [ID 451854 kern.warning] WARNING: glm1: timeout on bus reset interrupt
Apr 17 16:57:43 pampa rmclomv: [ID 218314 kern.error] FAULT_SENSOR @ MB.FF_SCSI has FAILED.
Apr 17 16:57:52 pampa pcisch: [ID 569400 kern.warning] WARNING: pcisch2: ino 0x28 blocked
Apr 17 16:57:52 pampa pcisch: [ID 548919 kern.info] glm-1#0
Apr 17 16:57:52 pampa pcisch: [ID 100033 kern.info]
Apr 17 16:58:16 pampa rmclomv: [ID 218314 kern.error] FAULT_SENSOR @ MB.FF_SCSI has FAILED.
Apr 17 16:58:56 pampa last message repeated 1 time

What are the part numbers and where did you get the disks?

All my X6250s hang in ESX 3.5 U5 with SCSI "command error recovery failed"

After installing a pair of Virtualized Network Expansion Modules (X4238) in our Blade 6000 chassis, my ESX 3.5 Update 5 hosts will randomly fail with the error "scsi: device might be offline - command error recovery failed: host 5 channel 0 id 0 lun 0." This does not represent LUNS on our Sun/Qlogic FC hbas (PCIe dual 4Gig). The old Dell blades sharing the FC LUNs are not experiencing any SCSI errors whatsoever. It appears to me this is referring to the VNEM's SAS fabric, but we have no SAS drive modules in the chassis. Is the fact that it sees other hosts on this fabric causing issues? I'd like to disable the SAS fabric, but don't see a way to do this via the BIOS or VNEM ILOM. Do you think I'm barking up the wrong tree?
Thanks,
Charles

Yes, I had updated the blade firmware to the current provided (though I see reference to a newer version in the docs, but not at the download site). However, it seems related to interrupt sharing with the NXGE card/driver under ESX 3.5. I have an open case with Sun, and while they suspected a known issue with the aacraid driver (ESX350-201003402-BG), that had already been installed. They're now asking to create a case with VMware. In the meantime, I've tested a pair of our X6250s without the NXGE, installing the original quad port GigE NIC (Intel). Those hosts are very stable. It may not be the VNEM at all, but I'll keep you posted.
Charles

Scsi offline or reservation conflict errors afer swapping HBAs

We swapped out all of our EMC branded Emulex LP10000 HBAs and replaced them with the Sun branded Emulex LP11000 (SG-XPCI1FC-EM4-Z). We now receive a steady stream of SCSI errors in /var/ad/messages similar to the following:
Nov 8 13:37:29 fhtulsaps201 scsi: [ID 107833 kern.warning] WARNING: /ssm@0,0/pci@19,600000/SUNW,emlxs@1/fp@0,0/ssd@w50060482d52dd0b7,16 (ssd27):
Nov 8 13:37:29 fhtulsaps201 offline or reservation conflict
These devices are target devices from a remote server and are kept in sync using EMCs RecoverPoint appliances. They are normally in a read write disabled state. I do not have access to SRDF but expect I would get the same errors since SRDF also puts the target devices in the same read write disabled state.
As you can see the messages file fills up rather quickly and is basically unusable.
root@fhtulsaps201# wc -l /var/adm/messages
208634 /var/adm/messages
root@fhtulsaps201# ls -l /var/adm/messages*
-rw-r--r-- 1 root root 28340369 Nov 8 13:52 /var/adm/messages
-rw-r--r-- 1 root root 94960043 Nov 7 03:07 /var/adm/messages.0
-rw-r--r-- 1 root root 94643625 Oct 31 03:08 /var/adm/messages.1
-rw-r--r-- 1 root root 113367276 Oct 24 03:07 /var/adm/messages.2
-rw-r--r-- 1 root root 118930213 Oct 17 03:08 /var/adm/messages.3
root@fhtulsaps201#
As a part of the HBA upgrade we applied several kernel patches so at this point I'm not sure if the new HBAs are to blame or one of the patches.
The old HBAs never produced these errors.
I would like to know it there's a way to reduce the logging output from the scsi driver.
Thanks for any help.

We see the same error, though not nearly in such abundance, on our Clariion systems when they are using "explicit trespass" mode. In this mode the "passive" path is completely inaccessible until a special control message is sent to it. Veritas sends that special control message when the primary path has failed (EMC's PowerPath does the same thing).
I know EMC recommends this because you should never end up with I/O going to the wrong service processor accidentally (a trespass) because it simply won't service such I/O's unless explicitly told to do so (gee, I wonder where the name explicit trespass came from? :)
I'd guess your RecoverPoint devices behave similarly.
The relevant code appears to this this bit from http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/scsi/targets/sd.c#9589:
   9570           /*
   9571            * If the target is not yet ready here (defined by a TUR
   9572            * failure), invalidate the geometry and print an 'offline'
   9573            * message. This is a legacy message, as the state of the
   9574            * target is not actually changed to SD_STATE_OFFLINE.
   9575            *
   9576            * If the TUR fails for EACCES (Reservation Conflict),
   9577            * SD_RESERVED_BY_OTHERS will be returned to indicate
   9578            * reservation conflict. If the TUR fails for other
   9579            * reasons, SD_NOT_READY_VALID will be returned.
   9580            */I'm not a SCSI expert by any stretch of the imagination, but it seems to me that either Solaris is misinterpreting the "EACCES" error code or EMC is mis-using it. Could be that there's no good code in the SCSI protocol to say "Yea, I'm here, but I won't talk to you right now" except this one.
This exists in the "sd_ready_and_valid" function which appears to be called any time I/O is attempted to the device if the geometry of the device is not yet known (which it never will be for these standby devices).
So, in summary, if your system can "see" a SCSI LUN which responds to a Test Unit Ready (TUR) with "EACCES" then you're going to be seeing these messages. I think your only hope it to check your systems carefully and find out what process is trying to do I/O to them and fix that process.
Best of luck!

Scsi errors on V240

Similar Messages

Maybe you are looking for