On Tue, 2002-10-22 at 20:50, Joe Ammann wrote: Hi all
with the help of IBM and our mainframe specialists, we have been able to
solve the problem. Turns out that our mainframes left in the old ESCON
adapters, and just marked them as not available (reason was so that they
could easily go back if there are problems with FICON).
So the channel group - excuse me, I'm pretty new in this 390 area, so
bear with me if I'm using the wrong terms - z/VM used as path to the
disked was composed of each 4 ESCON and 4 FICON channels. The ESCON ones
were logically disabled. The output of the Q PATH TO <devno> command of
z/VM looked something like this whilst the SuSE Linuxes were not
booting:
q path to b3e0
Device B3E0, Status ONLINE
CHPIDs to Device B3E0 (PIM) : 62 72 82 66 6A 7A 8A 6C
Physically Available (PAM) : - + - + + + + +
Online (LPM) : - - - - + + + +
Legend + Yes - No
Channels 62,72,82,66 are the ESCON channels, 6A,7A,8A,6C are the FICON
ones. Actually, the PAM should have disabled the old ESCON channels, but
somehow, the SuSE Linux DASD driver still tried to use it.
There was also some argument among our 390 specialists, that such a
configuration (ESCON and FICON mixed in a channel group) is "anyway
illegal" in the first place, and that SuSE Linux was quite right in
refusing to work in such an environment :-) But z/VM itsself and RedHat
were working fine, as mentioned.
Well anyway - as soon as all ESCON channels were marked as physically
_NOT_ available, the SuSE Linuxes were happy again - and working as a
charm. The output of the Q PATH TO <devno> then looked like:
q path to b3e0
Device B3E0, Status ONLINE
CHPIDs to Device B3E0 (PIM) : 62 72 82 66 6A 7A 8A 6C
Physically Available (PAM) : - - - - + + + +
Online (LPM) : - - - - + + + +
Legend + Yes - No
Just thought that I'd let you know in case anybody else goes through the
same upgrade :-)
CU, Joe
> Hi all
>
> we have been running happily several Linux instances un der z/VM 4.3.
> Last weekend, our storage subsystem has been upgraded from ESCON to a
> native FICON solution.
>
> Since then, I can't boot my SuSE Linux guests anymore. When I ipl CMS,
> the disks still appear and look fine. I can also ipl the Linux kernel of
> the DASD's, but right during the boot process (very early during kernel
> initialization) the following messages appear:
>
> --------------------------------------
> IPL 200
> hwc low level driver: can write messages
> hwc low level driver: can not read state change notifications
> hwc low level driver: can read commands
> hwc low level driver: can read priority commands
> Linux version 2.4.17-timer ([EMAIL PROTECTED]) (gcc version 2.95.3
> 20010
> SuSE)) #1 SMP Sat Apr 20 04:41:22 GMT 2002
> We are running under VM (64 bit mode)
> On node 0 totalpages: 65536
> zone(0): 65536 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: dasd=0200 root=/dev/dasda3 noinitrd
>
> Highest subchannel number detected (hex) : 000D
> SPID - Device 0191 on Subchannel 0004, lpm 40, became 'not operational'
> SPID - Device 0200 on Subchannel 0005, lpm 40, became 'not operational'
> SPID - Device 0201 on Subchannel 0006, lpm 40, became 'not operational'
> SPID - Device 0190 on Subchannel 000A, lpm 40, became 'not operational'
> SPID - Device 019D on Subchannel 000B, lpm 40, became 'not operational'
> SPID - Device 019E on Subchannel 000C, lpm 40, became 'not operational'
> SPID - Device 0120 on Subchannel 000D, lpm 40, became 'not operational'
> Calibrating delay loop... 979.76 BogoMIPS
> Memory: 248764k/262144k available (2243k kernel code, 0k reserved, 1126k
> -----------------------------------------------
>
> Then, when trying to mount the root filesystem, the kernel complains
> that the respective device mentioned in zipl doesn't exist. I guess,
> those ....became 'not operational' messages are the reason for my
> problems.
>
> Interestingly, I can still successfully boot my one single RedHat 7.2
> guest - which of course makes me believe that this problem has something
> to do with 31-bit vs. 64-bit.
>
> Any idea what's happening? I don't think that anything else than the
> ESCON/FICON upgrade was changed (of course, z/VM was IPL'd).
>
> CU, Joe
>
signature.asc
Description: This is a digitally signed message part
