SCSI\symmpi1 error

[J_Peralta]

Hi,

I've got an HP DL380 G4 server running Server 2003 and 11d, with an HP Dat72 Autoloader. I get the following error every now and again and the only resolution is to turn off the autoloader and turn it back on.

"The Device, \Device\Scsi\symmpi1, did not respond within the timeout period"

It happens midway through a job, sometimes at the end, not always the same job. It happens on various tapes/slots on the autoloader. There seems to be no consistency whatsoever.

I've tried changing the Target ID to 2 (as low as possible) and SCSI bus number but that didn't resolve the issue, only reduced the frequency that it happened. I've tried re-installing the drivers for the autoloader and Backup Exec seems to have a problem with the HP drivers so I've stuck with the symantec driver. All of the latest hotfixes have been applied and the problem is still happening.

I'm hoping someone else has had this same problem or can offer a solution.

Any help is much appreciated.

[Simon_L]

I have the same error with a service packed 10d

It's on a dl380 with an external hp ultrium 448 drive on a separete scsi controller

[Greg_Meister]

Hello,

Please check Windows Event Viewer, in the System event log. Look for any errors on the Symmpi device. While this may be a driver or firmware issue, usually this type of error resolves itself to the SCSI controller card, and would need to be addressed by that vendor. Your mention of the error occurring on random jobs, and at random points, is also indicative of this. If, for example, a backup job itself was corrupt, you would see consistent failures on a certain job, or on a specific resource.

Please let me know if you have any further questions, or if I can be of further assistance.

Regards,

Greg

[J_Peralta]

Greg,

Thanks for the response.  I've checked the Event viewer and searched the internet, MS and HP for info regarding it and come up with nothing relevant.  Most of the links in search engines reference a Dell server and they dont' offer too much help.  I've tried the things they suggest for the Dell servers. 

The error in the event log says:

-------------------------------------------------------------
Source: symmpi
Category: None
Event ID: 9

Description:
The device, \Device\Scsi\symmpi1, did not respond within the timeout period.

for more info see Help and support center at:
http://MSblahblahblah
-------------------------------------------------------------

When you click on the link it says that there is no further info at this time, yada yada yada, usual MS BS

Hopefully someone has encountered this before.  I've updated the firmware for the HP SCSI card, didn't do anything.  I've tried and failed with HP's tech support. 

Anyone with any info or suggestions is greatly appreciated.

Thanks,
J

Message Edited by J Peralta on 03-29-200712:03 PM

Message Edited by J Peralta on 03-29-200712:04 PM

[Greg_Meister]

J,

Is HP the hardware vendor for the tape hardware, the server hardware, or both. The reason I ask is because the evt ID 9, on source SYMMPI, is the SCSI controller that communicates to the tape hardware. So it's not a matter of troubleshooting the tape hardware, but the SCSI controller itself. They will need to resolve those event ID errors in order to clear up this issue.

Greg

[J_Peralta]

Greg,

Thanks again for your help.  Everything is HP - server, scsi card, autoloader.  That is also the problem...there isn't info on HPs forums (they aren't nearly as active as symantec) and their phone tech support is very un-helpful. 

I tried to move the SCSI controller to the 133Mhz PCI-X slot instead of the 100Mhz but that did nothing.  I took your suggestion and found some firmware updates for the SCSI card but I can't apply them until the current job gets done. 

Through a few times of trying various things, I've created a workaround for the problem.  Its very round-about and requires a bit of user intervetion but:

- put the job on hold
- turn off the autoloader & turn it back on
- move the tape from the drive to the library (without using the force drive to eject cartridge)
- right click the next tape in the set that didn't have the problem, click import
- an error will come up saying that there was a problem with the device, click OK
- un-hold the job, the drive will pull the tape that it locked up on, only to find that it is full
- click OK to the box about inserting media (as it is already in the library)
- the snapshot begins to process again and the job picks up where it left off.

I'll try the upgrades to the firmware and post the results when I get them.

Any other info anyone has is always appreciated.

J

[Michael_McKenne]

SCSI timeout.

1.) Shutdown and restart.   If its external tape device, shutdown server and external device.   Restart external device before you turn on the server and controller.  

2.) Check cable and terminator.  I have seen on a Sony AIT drive that a 3 foot cable worked better than a 6 foot cable.  

IDs don't matter unless they are same as other devices.  Upgrade SCSI controller firmware and drivers to latest.  Get latest firmware for tape devices. 

[J_Peralta]

Michael,

Thanks for the input.

1.  That was the first thing I tried a while back.  I did it in that order too.  It didn't solve the problem permanently, only allowed it to start working again.  It also cancels the job and the workaround above is to continue the job once it happens without having to restart the server itself.

2.  The cable and terminator are properly plugged in.  It is using a 6 ft. cable so what I might do is get a smaller cable if nothing else works

I just updated the firmware for the SCSI controller and started a 225GB backup job.  We'll see how it goes.  I'll be sure to post the results and link if it works.  Otherwise I'll be back on with more info.

Thanks
J

[L__Quarton]

  We started migrating our ROBO systems from Novell to Windows 2003 and from B.E. 9x to 11d.  Some of these systems have legacy 4MMDATs or DAT72s and some have VXA-3s, which is where all of them are heading. 

 I have experienced the same driver error as mentioned on this thread, but not just that driver.  I have had about 3-4 different drivers - all current - exhibit this same behavior with 11d.  A couple of them are drivers we've used forever, ("4mmdat" for example) but the "symmpi1" driver is being used for the first time in these servers. I tried using "sonysdx" too - same errors. The servers are HP, the DAT drives are too, but of course the VXAs are Exabyte.

 Our main media server here at HQ has been using 3 VXA autoloaders (10x1U) for over 2 years (B.E. 10x and 11x) with no problems at all, and great performance, and another media server has been using a single VXA autoloader for over a year, on a Win2000 B.E. 9.x system with no issues. 

 I'm out of ideas on all these driver errors - all the same as was pasted on this thread RE: symmpi1. 

The various drivers react differently to these errors, and 2 of these servers have such bad throughput (20-50MB/min) they are currently dumping backups to a remote disk until we can get the VXA-3 installed. 

 Is this for sure and certain a controller issue?  I can't recommend buying new cards unless I have some documentation these older cards are not compatible with B.E. 11d.

These drivers are working on the main media server with the 3 VXA autoloaders:

0001:0000:0000:0000  "atapi", (Port Driver)

-------------------  -------------------------------------------------------------------------------

0002:0000:0000:0000  "adpu160m", (Port Driver)
0002:0000:0001:0000  "EXABYTE VXA 1x10 1U     A108", (Changer Device), "\\.\MediumChanger0"
0002:0000:0002:0000  "EXABYTE VXA-2           210D", (Tape Device), "\\.\Tape0"
0002:0000:0004:0000  "EXABYTE VXA 1x10 1U     A10D", (Changer Device), "\\.\MediumChanger1"
0002:0000:0005:0000  "EXABYTE VXA-2           210E", (Tape Device), "\\.\Tape1"

-------------------  -------------------------------------------------------------------------------

0003:0000:0000:0000  "adpu160m", (Port Driver)
0003:0000:0000:0000  "EXABYTE VXA 1x10 1U     A105", (Changer Device), "\\.\MediumChanger2"
0003:0000:0003:0000  "EXABYTE VXA-2           210D", (Tape Device), "\\.\Tape2"

-------------------  -------------------------------------------------------------------------------

0004:0000:0000:0000  "cpqcissm", (Port Driver)

Message Edited by L. Quarton on 04-05-200702:10 AM

[Greg_Meister]

SYMMPI is usually (in my experience) found to be an on-board SCSI controller. The ADPU160M is one flavor of driver for Adaptec SCSI controllers. So, a failure on one controller and success on another is not unusual.

These type of errors are not specific to SYMMPI1, but more an issue between controllers and the attached tape hardware. Microsoft has a KB article that references the most common errors seen: http://support.microsoft.com/?kbid=154690

As stated in the KB, these errors CAN be driver related. But, if you've replaced or upgraded drivers, and are still seeing these errors, it's unlikely to be a driver problem.

[Michael_McKenne]

I see three VXA-2 1x10 packet loaders.   I would make sure all the firmware on the loaders and tape drives are at the latest levels.

VXA-2 tape drives should be at 2120

VXA-2 1x10 1U packet loader should be V1A10E

This will help with SCSI timeout issues.  

I would also use the Adaptec 39160 drivers from Adaptec's site over the MS native Adaptec drivers.  I had onboard SCSI on several Tyan boards and had no issues using the Adaptec drivers with it. 

0001:0000:0000:0000  "atapi", (Port Driver)

-------------------  -------------------------------------------------------------------------------

0002:0000:0000:0000  "adpu160m", (Port Driver)
0002:0000:0001:0000  "EXABYTE VXA 1x10 1U     A108", (Changer Device), "\\.\MediumChanger0"
0002:0000:0002:0000  "EXABYTE VXA-2           210D", (Tape Device), "\\.\Tape0"
0002:0000:0004:0000  "EXABYTE VXA 1x10 1U     A10D", (Changer Device), "\\.\MediumChanger1"
0002:0000:0005:0000  "EXABYTE VXA-2           210E", (Tape Device), "\\.\Tape1"

-------------------  -------------------------------------------------------------------------------

0003:0000:0000:0000  "adpu160m", (Port Driver)
0003:0000:0000:0000  "EXABYTE VXA 1x10 1U     A105", (Changer Device), "\\.\MediumChanger2"
0003:0000:0003:0000  "EXABYTE VXA-2           210D", (Tape Device), "\\.\Tape2"

-------------------  -------------------------------------------------------------------------------

0004:0000:0000:0000  "cpqcissm", (Port Driver)

[Rick_Wagner_2]

I was able to fix the error with the download of the latest driver from the HP site.  My previous driver had a date of 2002 and the new one was in 2004.

[Michael_McKenne]

Good to hear.