Susan Zimmerman wrote:
Hi Listers,
We had an issue over the weekend when the microcode was upgraded on all our
DS8000s . According to the CE, about 5 hours after the microcode was
installed, the two PCHIDs connected to our SCSI DS8000 started posting
error messages every 6 seconds.
I logged on to one of our test systems and cd'ed to the directory mounted
on the scsi disk. When I issued the ls command, my linux went to sleep and
never came back.
Our fcp is defined using EDEVs...so using MAINT, I then issued the Q EDEV
command and it just locked up MAINT. The following messages appeared on
OPERATOR (every minute):
HCPMHT2150I DASD 0E01 and interrupt is pending
HCPMHT6304I IRB= (all zeroes)
HCPMHT6305I Userid=LNXCUPT
I am particularly ignorant on this, but isn't this a problem with VM
and/or the hardware? If VM gets stuck, what chance has Linux got?
We eventually forced the linux guest down and shutdown z/VM and then
toggled the PCHID off/on which cleared up the error. I was able to IPL
both z/VM and the linux guest and had no problems getting to the data.
Our CE wonders if it was CUIR ... it looks like CUIR works for z/OS and
z/VM environements... but can't tell whether this is CKD or if it works for
FBA too. Aside from that, I wonder if zLinux (SLES 9) can handle it. I
pasted a blurb from the DS8000 Architecture and Implementation redbook
below.
Control Unit Initiated Reconfiguration
Control Unit Initiated Reconfiguration (CUIR) prevents loss of access to
volumes in System z
environments due to wrong path handling. This function automates channel
path
management in System z environments, in support of selected DS8000 service
actions.
Control Unit Initiated Reconfiguration is available for the DS8000 when
operated in the z/OS
and z/VM environments. The CUIR function automates channel path vary on and
vary off
actions to minimize manual operator intervention during selected DS8000
service actions.
CUIR allows the DS8000 to request that all attached system images set all
paths required for
a particular service action to the offline state. System images with the
appropriate level of
software support will respond to such requests by varying off the affected
paths, and either
notifying the DS8000 subsystem that the paths are offline, or that it
cannot take the paths
offline. CUIR reduces manual operator intervention and the possibility of
human error during
maintenance actions, at the same time reducing the time required for the
maintenance. This
is particularly useful in environments where there are many systems
attached to a DS8000.
Has anyone experienced this problem before? I've instructed the CE to make
sure the DEVL and TEST z/VM systems are down when he does any microcode
updates to this DS8000 in the future. Our PROD z/VM can stay up since we
don't have production running with fcp dasd... but unless there is a
solution, I don't want to put production data on our SCSI DS8000 since I
can't afford to take a long outage.
Thanks in advance for any advice.
susan
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
