Re: dedicate DASD "not operational" under z/VM 4.1
Holger, you confuse me - we can deal with VM rejecting our SPID requests. Worked fine with minidisk and dedicated disks in the past. Did smth change ? Best regards, Ingo ** Ingo Adlung, Linux for zSeries - Strategy & Design The box said, 'Requires Windows95 or better' , ...so I installed LINUX. Holger Smolinski/Germany/IBM@[EMAIL PROTECTED]> on 29.01.2002 16:33:07 Please respond to Linux on 390 Port <[EMAIL PROTECTED]> Sent by: Linux on 390 Port <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: [LINUX-390] dedicate DASD "not operational" under z/VM 4.1 Did you define the DASDs as 'unsupported' in z/VM? z/VM imagining the device to be supported by itself prevents it from allowing a SetPathGroupID. Best Regards Holger Smolinski -- Dr. Holger Smolinski, Tech. Planning (Storage I/O) for Linux on zSeries IBM Deutschland Entwicklung GmbH,Schönaicher Str. 220, 71032 Böblingen FAX: +49-7031-16-3456, Tel. +49-7031-16-4652 |+---> || "Ferguson, Neale"| || | || Sent by: Linux on 390| || Port | || <[EMAIL PROTECTED]>| || | || | || 29.01.02 15:44 | || Please respond to Linux | || on 390 Port | || | |+---> > ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: dedicate DASD "not operational" under z/VM 4.1 | | | | | > ---| What does a query of the real devices show? What does the CP directory entry of the Linux guest look like? > -Original Message- > Hi, > We installed Linux under z/VM 4.1 which is upgraded > from VM 2.4. Yesterday we restart the VM include all > related hardware power off/power on because of > maintainence reason (just restart, not change in > system), but after that we cannot start the linux > servers properly. Now Linux can only detect the > minidisk but not dedicate volumes any more. > The System log is: > > Ready; T=0.01/0.01 09:06:08 > i 100 > Linux version 2.2.19 ([EMAIL PROTECTED]) (gcc > version 2.95.2.1 19991024 (release)) #1 SMP Thu May 24 > 12:43:49 PDT 2001 > Command line is: root=/dev/dasda1 ro noinitrd > dasd=100,200,1729-172b,119
Re: dedicate DASD "not operational" under z/VM 4.1
Did you define the DASDs as 'unsupported' in z/VM? z/VM imagining the device to be supported by itself prevents it from allowing a SetPathGroupID. Best Regards Holger Smolinski -- Dr. Holger Smolinski, Tech. Planning (Storage I/O) for Linux on zSeries IBM Deutschland Entwicklung GmbH,Schönaicher Str. 220, 71032 Böblingen FAX: +49-7031-16-3456, Tel. +49-7031-16-4652 |+---> || "Ferguson, Neale"| || | || Sent by: Linux on 390| || Port | || <[EMAIL PROTECTED]>| || | || | || 29.01.02 15:44 | || Please respond to Linux | || on 390 Port | || | |+---> >---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: Re: dedicate DASD "not operational" under z/VM 4.1 | | | | | >---| What does a query of the real devices show? What does the CP directory entry of the Linux guest look like? > -Original Message- > Hi, > We installed Linux under z/VM 4.1 which is upgraded > from VM 2.4. Yesterday we restart the VM include all > related hardware power off/power on because of > maintainence reason (just restart, not change in > system), but after that we cannot start the linux > servers properly. Now Linux can only detect the > minidisk but not dedicate volumes any more. > The System log is: > > Ready; T=0.01/0.01 09:06:08 > i 100 > Linux version 2.2.19 ([EMAIL PROTECTED]) (gcc > version 2.95.2.1 19991024 (release)) #1 SMP Thu May 24 > 12:43:49 PDT 2001 > Command line is: root=/dev/dasda1 ro noinitrd > dasd=100,200,1729-172b,119
Re: dedicate DASD "not operational" under z/VM 4.1
Hi List, we've seen this problem before. Our investigation shows: - devices respond to SenseID in a correct way - devices respond to SetPathGroupID with a "deferred not operational" We think this problem is due to VM (other scenario was also caused by VM upgrade). Currently, VM folks are investigating this. mit freundlichem Gruß / with kind regards Carsten Otte IBM Deutschland Entwicklung GmbH Linux for eServer development - device driver team Phone: +49/07031/16-4076 IBM internal phone: *120-4076 -- We are Linux. Resistance indicates that you're missing the point!
Re: dedicate DASD "not operational" under z/VM 4.1
What does a query of the real devices show? What does the CP directory entry of the Linux guest look like? > -Original Message- > Hi, > We installed Linux under z/VM 4.1 which is upgraded > from VM 2.4. Yesterday we restart the VM include all > related hardware power off/power on because of > maintainence reason (just restart, not change in > system), but after that we cannot start the linux > servers properly. Now Linux can only detect the > minidisk but not dedicate volumes any more. > The System log is: > > Ready; T=0.01/0.01 09:06:08 > i 100 > Linux version 2.2.19 ([EMAIL PROTECTED]) (gcc > version 2.95.2.1 19991024 (release)) #1 SMP Thu May 24 > 12:43:49 PDT 2001 > Command line is: root=/dev/dasda1 ro noinitrd > dasd=100,200,1729-172b,119
dedicate DASD "not operational" under z/VM 4.1
Hi, We installed Linux under z/VM 4.1 which is upgraded from VM 2.4. Yesterday we restart the VM include all related hardware power off/power on because of maintainence reason (just restart, not change in system), but after that we cannot start the linux servers properly. Now Linux can only detect the minidisk but not dedicate volumes any more. The System log is: Ready; T=0.01/0.01 09:06:08 i 100 Linux version 2.2.19 ([EMAIL PROTECTED]) (gcc version 2.95.2.1 19991024 (release)) #1 SMP Thu May 24 12:43:49 PDT 2001 Command line is: root=/dev/dasda1 ro noinitrd dasd=100,200,1729-172b,119 We are running under VM This machine has an IEEE fpu Detected device 0192 on subchannel - PIM = FF, PAM = FF, POM = FF Detected device 0800 on subchannel 0001 - PIM = 80, PAM = 80, POM = FF Detected device 0801 on subchannel 0002 - PIM = 80, PAM = 80, POM = FF Detected device 0802 on subchannel 0003 - PIM = 80, PAM = 80, POM = FF Detected device 0803 on subchannel 0004 - PIM = 80, PAM = 80, POM = FF Detected device 0100 on subchannel 0005 - PIM = FF, PAM = FF, POM = FF Detected device 0119 on subchannel 0006 - PIM = FF, PAM = FF, POM = FF Detected device 1729 on subchannel 0007 - PIM = FF, PAM = FF, POM = FF Detected device 172A on subchannel 0008 - PIM = FF, PAM = FF, POM = FF Detected device 172B on subchannel 0009 - PIM = FF, PAM = FF, POM = FF Detected device 0191 on subchannel 000A - PIM = FF, PAM = FF, POM = FF Detected device 0200 on subchannel 000B - PIM = FF, PAM = FF, POM = FF Detected device 001F on subchannel 000C - PIM = 80, PAM = 80, POM = FF Detected device 000C on subchannel 000D - PIM = 80, PAM = 80, POM = FF Detected device 000D on subchannel 000E - PIM = 80, PAM = 80, POM = FF Detected device 000E on subchannel 000F - PIM = 80, PAM = 80, POM = FF Detected device 0190 on subchannel 0010 - PIM = FF, PAM = FF, POM = FF Detected device 019D on subchannel 0011 - PIM = FF, PAM = FF, POM = FF Detected device 019E on subchannel 0012 - PIM = FF, PAM = FF, POM = FF Detected device 0592 on subchannel 0013 - PIM = FF, PAM = FF, POM = FF Highest subchannel number detected (hex) : 0013 SenseID : device 0192 reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/0A SenseID : device 0800 reports: Dev Type/Mod = 3088/08 SenseID : device 0801 reports: Dev Type/Mod = 3088/08 SenseID : device 0802 reports: Dev Type/Mod = 3088/08 SenseID : device 0803 reports: Dev Type/Mod = 3088/08 SenseID : device 0100 reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/06 SPID - Device 0100 on Subchannel 0005 became 'not operational' SPID - Device 0100 on Subchannel 0005 became 'not operational' SPID - Device 0100 on Subchannel 0005 became 'not operational' SPID - Device 0100 on Subchannel 0005 became 'not operational' SenseID : device 0119 reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/0A SPID - Device 0119 on Subchannel 0006 became 'not operational' SPID - Device 0119 on Subchannel 0006 became 'not operational' SPID - Device 0119 on Subchannel 0006 became 'not operational' SPID - Device 0119 on Subchannel 0006 became 'not operational' SenseID : device 1729 reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/06 SPID - Device 1729 on Subchannel 0007 became 'not operational' SPID - Device 1729 on Subchannel 0007 became 'not operational' SPID - Device 1729 on Subchannel 0007 became 'not operational' SPID - Device 1729 on Subchannel 0007 became 'not operational' SenseID : device 172A reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/06 SPID - Device 172A on Subchannel 0008 became 'not operational' SPID - Device 172A on Subchannel 0008 became 'not operational' SPID - Device 172A on Subchannel 0008 became 'not operational' SPID - Device 172A on Subchannel 0008 became 'not operational' SenseID : device 172B reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/06 SPID - Device 172B on Subchannel 0009 became 'not operational' SPID - Device 172B on Subchannel 0009 became 'not operational' SPID - Device 172B on Subchannel 0009 became 'not operational' SPID - Device 172B on Subchannel 0009 became 'not operational' SenseID : device 0191 reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/06 SenseID : device 0200 reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/06 SenseID : device 001F reports: Dev Type/Mod = 3215/00 SenseID : device 000C reports: Dev Type/Mod = 2540/00 SenseID : device 000D reports: Dev Type/Mod = 2540/00 SenseID : device 000E reports: Dev Type/Mod = 1403/00 SenseID : device 0190 reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/0A SenseID : device 019D reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/0A SenseID : device 019E reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/0A SenseID : device 0592 reports: CU Type/Mod = 3990/E9, Dev Type/Mod = 3390/0A Calibrating delay loop... 411.23 BogoMIPS Memory: 62424k/65536k available (1296k kernel code, 4k reserved, 1812k data, 0k init) Dentry hash table entries: 8192 (order 4, 64k) Buffer cache hash table entries: 65536 (order 6, 256k) Page cache hash table
