On Sun, Nov 25, 2007 at 05:26:11PM +0100, MAYER Andreas wrote: > we are using FCP attached tape devices on SLES 9 s390x SP3 for TSM for > over one year now, in the last weeks we've added other tape models from > same vendor.
What is the exact kernel version? Is it the latest available update for SP3 (-287.3) or something older? > After getting syslog message "kernel: zfcp: warning: unknown incoming > ELS 0x21100014 for adapter 0.0.c108" we have troubles with some to all > tape devices on this fcp adapter. > On another fcp adapter on the same system a second set of the same tape > devices is working without problems. > > If we try to reset the fcp adapter with chccwdev -d/-e, IO's on the tape > devices are working for some time, but after message "kernel: zfcp: > warning: unknown incoming ELS 0x21100014 for adapter 0.0.c108" the tape > devices stop working again. > > Extended Link Services (ELS) 0x21100014 appears to be PRLO (Process > Logout). > I did search for some more information in the internet, did find some > issues if scsi initiator does not login again to target after PRLO ? > > Currently I'm trying to get more information by looking at fcp trace > data produced while testing with TSM mttest command. > In the trace I see that the target port and unit is reopened (and a soft > error is returned to the application ?): > zfcp: zfcp_erp_port_forced_reopen_internal(499): forced reopen of port > 0x500104f000752a69 on adapter 0.0.c108 > zfcp: zfcp_fsf_send_fcp_command_task_handler(4162): Setting > DID_SOFT_ERROR and SUGGEST_RETRY > zfcp: zfcp_fsf_send_fcp_command_task_handler(4333): scpnt->result > =0x100b0000 > zfcp: zfcp_fsf_open_unit_handler(3317): unit 0x0000000000000000 on > remote port 0x500104f000752a69 on adapter 0.0.c108 opened, port handle > 0x516 > > Does anyone have an idea what's going on here or why the zfcp driver > doesn't handle PRLO ? zfcp does not use PRLO and normally does not have to handle these ELS events. zfcp only uses the ADISC ELS to check if a remote port is still available. Everything related to login and logout requests in the FC-SAN is handled by the FCP adapter. So the question here would be: What is the reason for the PRLO? Probably you could check the logs of the SAN switches to see if something happened there. Looking at the zfcp code, the PRLO also should not trigger the "forced reopen" of the port, so it looks like something else is also happening here with the port. You could also check the entries in: /proc/s390dbf/zfcp_0.0.c108_san/structured Here you will find all outgoing and incoming ELS requests together with the payload and the source and destination d_id. Probably this will help finding the reason for this request. Christof ---------------------------------------------------------------------- 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
