TLB Exception causes E1200 to reboot

[Ian Grobler]

Recently I have seen a strange issue on two seperate sites with similar infrastructure.
Scenario: MSL5030 LTO Library (FW 0430) with a LTO Drive (FW E38W) connected to a SAN via a onboard E1200 (FW 5606). While running a backup (Data Protector 5.1 with necessary patches) an error occurs on the Tape which raises and exception on the Tape Library. The E1200 interprets this exception as some sort of hardware error and reboots itself.

Surely this is incorrect? A problem with a faulty tape should not cause a re-initialize of the complete E1200. The exception being raised is internal between the E1200 and MSL5030(?) so I cannot see software being involved unless DP5.1 is causing this TLB exception on the Library.
Recently another site with a slightly older version of E1200 Firmware has done the same thing after a couple of errors on a tape. Any ideas? Sample of the E1200 event logs attached.

[Marino Meloni_1]

I have two suggestion:

first, log on to the serial port and reset to default value the NSR, this will reset some filds inside the unit used to store data by the bios.

second try to downgrade the version to the previous one and observe if it will solve

[Ian Grobler]

Thanks, I have been waiting for some time from the customer to reset the E1200. As we are dealing with the same issue/exception on different versions of firmware I don't think changing firmware will make a difference. I will reset to defaults and setup from scratch to see if the makes a difference.

[Ian Grobler]

I have reset the E1200 to defaults last week and set it up from scratch again. As soon as a tape error occurs I will be able to tell if this has helped (Let's hope so!).

[Marino Meloni_1]

A new info, I got, it your NSR is connected to the lan, some monitoring sw can cause the NSR to reboot after exeptions. To identify if this is the cause of your reboot, you have to let the lan cable disconnect, or connect it to a PC dircectly with a crossed cable

[Ian Grobler]

Yes, the E1200's in question are connected to their respective LAN's via the Ethernet with a fixed IP configured. I am not aware of any tools which may be actively monitoring these but this definitely cannot be ruled out. I am still awaiting a tape issue after the reset to see how it goes. Will let you know when/if this occurs. Your advice much appreciated!

[Bernhard Krieg_1]

All those routers seem to reboot if they get a certain kind of packet. I first suspected SNMP but this also happens when plugged in to a disabled port on our Cisco-Switches.
(idea was to disable the port on the switch and simply enable it to be able to manage the NSRs)
The only solution is to pull ethernet and plug it in when you need to manage the router.
This problem exits since i use these routers and HP (or Crossroads) don't get this problem fixed, so it's a waste of time going back to an older version!

Bernhard

[Ian Grobler]

Unfortunately resetting the E1200 to defaults and setting up from scratch did not help - as soon as there were errors writing to tape during a backup a TLB exception occurred on the MSL5030 and the E1200 rebooted. I have seen this on two independant systems this week again. I have not tried removing the E1200 from the LAN as yet - I would lose all remote manageability if I do this at the moment.
Even if there may be some errors on a tape or a drive is acting up it should NOT cause the E1200 to reboot - this just does not make sense. I have attached a E1200 report from one of the two problem sites.. any advice would be most welcome.

[David Ruska · Accepted solution]

1) You may want to update to 5.6.69 firmware, as it has some fixes for assertions and TLBs.

---
Fixed between versions 5606 and 5669
Several fixes for Assertions and TLBs

FC ports with nothing attached will no longer fill up the Event Log

The default Target Rest mode is now Alternate

Several SCSI and fibre protocol fixes to improve reliability

Fixed an issue with tape spanning
---

2) If you are still having problems after that, then see if you can eliminate them by disconnecting the LAN (as a short term solution).

3) If the product is still under support, call your HP support center and open a case to investigate root cause.

[David Ruska]

Ian,

We took a look at the event logs you provided. There were two snipits that showed one TLB each on two routers back in January, one on 5.4.25, and another on 5.6.06. We'll check to see if there's anything the code addresses might reveal, but without a previous boot trace there's not much to go on.

The more recent report page you provided does not show any TLBs or reboots since 2/10/05 (start of the log). It does show two SCSI bus resets after a SCSI "write buffer" command (3C) to the drive failed to be sent. The are also 3 errors returned from a drive at different times (2 hardware errors, one medium (tape) error).

Can you provide us the report page for the other router?