Re: hipersockets don't come up after HW upgrade
Hi, Ursula uname -a Linux DPRODDB2 2.6.32.46-0.3-default #1 SMP 2011-09-29 17:49:31 +0200 s390x s390x s390x GNU/Linux lsqeth ... [other devices] Device name : hsi0 - card_type : HiperSockets cdev0 : 0.0.7000 cdev1 : 0.0.7001 cdev2 : 0.0.7002 chpid : F1 online : 1 portname: no portname required portno : 0 state : SOFTSETUP priority_queueing : always queue 2 buffer_count: 16 layer2 : 1 isolation : none I am attaching the results of the dmesg command Med vennlig hilsen Roger Evans On Mon, 2011-11-07 at 16:53 +0100, Ursula Braun wrote: > Roger, > > the minimum SLES11 SP1 kernel level should be 2.6.32.29-0.3.1. If you > still have problems with a kernel level greater or equal to this one, > something else is wrong. Which qeth-related messages show up in dmesg? > What does "lsqeth" return? > > Regards, Ursula Braun, IBM Germany > > On Mon, 2011-11-07 at 16:04 +0100, Roger Evans wrote: > > Thank you Ursula > > > > I don't seem to have the permissions to read those bugzilla entries, or > > maybe I'm looking in the wrong Novell Bugzilla. > > > > Upgrading from sp3 to sp4 solved the problem for SLES10. > > > > I upgraded my SLES11sp1 with all the upgrades SuSE provides, but still > > get the following msg: > > -- > > DPRODDB2:~ # ifup hsi0 > > hsi0 name: Hipersocket (0.0.7000) > > RTNETLINK answers: Unknown error 18446744073709486085 > > Cannot enable interface hsi0. > > interface hsi0 is not up > > - > > > > I will go through the steps in the hipersocket configuration > > instructions again. Maybe it's not enough to define it in YAST.. > > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.32.46-0.3-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP 2011-09-29 17:49:31 +0200 setup.1a06a7: Linux is running as a z/VM guest operating system in 64-bit mode Zone PFN ranges: DMA 0x -> 0x0008 Normal 0x0008 -> 0x0010 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x0010 On node 0 totalpages: 1048576 DMA zone: 7168 pages used for memmap DMA zone: 0 pages reserved DMA zone: 517120 pages, LIFO batch:31 Normal zone: 7168 pages used for memmap Normal zone: 517120 pages, LIFO batch:31 PERCPU: Embedded 11 pages/cpu @8408 s12544 r8192 d24320 u65536 pcpu-alloc: s12544 r8192 d24320 u65536 alloc=16*4096 pcpu-alloc: [0] 00 [0] 01 [0] 02 [0] 03 [0] 04 [0] 05 [0] 06 [0] 07 pcpu-alloc: [0] 08 [0] 09 [0] 10 [0] 11 [0] 12 [0] 13 [0] 14 [0] 15 pcpu-alloc: [0] 16 [0] 17 [0] 18 [0] 19 [0] 20 [0] 21 [0] 22 [0] 23 pcpu-alloc: [0] 24 [0] 25 [0] 26 [0] 27 [0] 28 [0] 29 [0] 30 [0] 31 pcpu-alloc: [0] 32 [0] 33 [0] 34 [0] 35 [0] 36 [0] 37 [0] 38 [0] 39 pcpu-alloc: [0] 40 [0] 41 [0] 42 [0] 43 [0] 44 [0] 45 [0] 46 [0] 47 pcpu-alloc: [0] 48 [0] 49 [0] 50 [0] 51 [0] 52 [0] 53 [0] 54 [0] 55 pcpu-alloc: [0] 56 [0] 57 [0] 58 [0] 59 [0] 60 [0] 61 [0] 62 [0] 63 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1034240 Kernel command line: root=/dev/disk/by-path/ccw-0.0.0100-part1 TERM=dumb BOOT_IMAGE=0 PID hash table entries: 4096 (order: 3, 32768 bytes) Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Memory: 4105820k/4194304k available (4398k kernel code, 0k reserved, 2099k data, 228k init) Write protected kernel read-only data: 0x10 - 0x5f Hierarchical RCU implementation. console [ttyS0] enabled allocated 41943040 bytes of page_cgroup please try 'cgroup_disable=memory' option if you
Re: hipersockets don't come up after HW upgrade
Roger, the minimum SLES11 SP1 kernel level should be 2.6.32.29-0.3.1. If you still have problems with a kernel level greater or equal to this one, something else is wrong. Which qeth-related messages show up in dmesg? What does "lsqeth" return? Regards, Ursula Braun, IBM Germany On Mon, 2011-11-07 at 16:04 +0100, Roger Evans wrote: > Thank you Ursula > > I don't seem to have the permissions to read those bugzilla entries, or > maybe I'm looking in the wrong Novell Bugzilla. > > Upgrading from sp3 to sp4 solved the problem for SLES10. > > I upgraded my SLES11sp1 with all the upgrades SuSE provides, but still > get the following msg: > -- > DPRODDB2:~ # ifup hsi0 > hsi0 name: Hipersocket (0.0.7000) > RTNETLINK answers: Unknown error 18446744073709486085 > Cannot enable interface hsi0. > interface hsi0 is not up > - > > I will go through the steps in the hipersocket configuration > instructions again. Maybe it's not enough to define it in YAST.. > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mvsdasd
On Monday, 11/07/2011 at 11:12 EST, Richard Gasiorowski wrote: > Robert - the read-only seemed harmless and as far as security that > could get ugly, We sue CA TSS thru PAM calls and I would not want even > ask what that would cause. really thank you for taking the time The bottom line is that unless you have a problem on z/OS that is solved by mvsdasd, don't use it, as it adds problems of its own that don't have good solutions. The security issues pretty much kill it. Definitely read those old posts. Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mvsdasd
On Mon, Nov 7, 2011 at 3:48 PM, RPN01 wrote: > Since you got no replies, I took a quick look at the site. Since it creates > a read-only mount, I don't see how you're going to hurt anything, so that > would eliminate any of the "scary" portion, in terms of Sysplex membership > concerns. Mounting R/O does not prevent Linux from doing a reserve against the volume. Sure, as long as you run Linux on z/VM you can stop writes just there. I do recall stories from people playing with Linux in LPAR and holding a reserve on the RACF database for example... Rob -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mvsdasd
Robert - the read-only seemed harmless and as far as security that could get ugly, We sue CA TSS thru PAM calls and I would not want even ask what that would cause. really thank you for taking the time Richard (Gaz) Gasiorowski Solution Architect CSC 3170 Fairview Park Dr., Falls Church, VA 22042 845-889-8533|Work|845-392-7889 Cell|rgasi...@csc.com|www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: RPN01 To: LINUX-390@vm.marist.edu Date: 11/07/2011 10:54 AM Subject: Re: mvsdasd Since you got no replies, I took a quick look at the site. Since it creates a read-only mount, I don't see how you're going to hurt anything, so that would eliminate any of the "scary" portion, in terms of Sysplex membership concerns. Security concerns should be controlled from a z/VM standpoint, in that if you don't want the Linux image to see it, don't give it a link to the disk. If you're worried about a rogue z/VM administrator, he's got CMS, which could do far more damage than a Linux image. The mvsdasd driver doesn't support pdse or vsam, so it can't see most of what z/OS does these days. I'm not too sure how useful it would be, other than to get a view into flat files for the exchange of information meant specifically for z/OS to Linux communications. On this point, it could be fairly handy, but most sites will already have ftp or nfs traffic in place to do this. Giving access to an entire disk to access a single text file doesn't seem practical, and doesn't account for the fact that files' locations aren't fixed in z/OS, so a great deal of legwork would be involved just in locating the file and setting up the transaction, where FTP could be far more simple and straight forward. The driver itself makes a number of assumptions about the way z/OS sites "do business" that smack of 1980's thinking. The z/OS world generally doesn't work this way any more at the majority of sites, which leaves this technology in the dust. In today's world, you never specify the volume where a file will be created. The system takes care of this, based on standards set up by the administrators. It certainly wouldn't work here at all. I wouldn't even be able to get the "security file" on a volume here, as its name doesn't fit into the file naming standard here. The high-level-qualifier doesn't match anything used here, and so could never be created. They've written this for their own site, without any thought about what might be required anywhere else. It's a product that solved problems 30 years ago. It just got written far too late. Hope this helps. -- Robert P. Nix Mayo Foundation.~. RO-OC-1-18 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 11/6/11 2:19 PM, "Richard Gasiorowski" wrote: > Going to ask again since the first message was so popular I received no > responses. has anyone used this driver from mvsdasd.org? Interested in > any experience comments and gotcha's. Seems scary to open up z/VM access > to z/OS DASD which is a member of a sysplex. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: mvsdasd
Since you got no replies, I took a quick look at the site. Since it creates a read-only mount, I don't see how you're going to hurt anything, so that would eliminate any of the "scary" portion, in terms of Sysplex membership concerns. Security concerns should be controlled from a z/VM standpoint, in that if you don't want the Linux image to see it, don't give it a link to the disk. If you're worried about a rogue z/VM administrator, he's got CMS, which could do far more damage than a Linux image. The mvsdasd driver doesn't support pdse or vsam, so it can't see most of what z/OS does these days. I'm not too sure how useful it would be, other than to get a view into flat files for the exchange of information meant specifically for z/OS to Linux communications. On this point, it could be fairly handy, but most sites will already have ftp or nfs traffic in place to do this. Giving access to an entire disk to access a single text file doesn't seem practical, and doesn't account for the fact that files' locations aren't fixed in z/OS, so a great deal of legwork would be involved just in locating the file and setting up the transaction, where FTP could be far more simple and straight forward. The driver itself makes a number of assumptions about the way z/OS sites "do business" that smack of 1980's thinking. The z/OS world generally doesn't work this way any more at the majority of sites, which leaves this technology in the dust. In today's world, you never specify the volume where a file will be created. The system takes care of this, based on standards set up by the administrators. It certainly wouldn't work here at all. I wouldn't even be able to get the "security file" on a volume here, as its name doesn't fit into the file naming standard here. The high-level-qualifier doesn't match anything used here, and so could never be created. They've written this for their own site, without any thought about what might be required anywhere else. It's a product that solved problems 30 years ago. It just got written far too late. Hope this helps. -- Robert P. Nix Mayo Foundation.~. RO-OC-1-18 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 11/6/11 2:19 PM, "Richard Gasiorowski" wrote: > Going to ask again since the first message was so popular I received no > responses. has anyone used this driver from mvsdasd.org? Interested in > any experience comments and gotcha's. Seems scary to open up z/VM access > to z/OS DASD which is a member of a sysplex. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: hipersockets don't come up after HW upgrade
Thank you Ursula I don't seem to have the permissions to read those bugzilla entries, or maybe I'm looking in the wrong Novell Bugzilla. Upgrading from sp3 to sp4 solved the problem for SLES10. I upgraded my SLES11sp1 with all the upgrades SuSE provides, but still get the following msg: -- DPRODDB2:~ # ifup hsi0 hsi0 name: Hipersocket (0.0.7000) RTNETLINK answers: Unknown error 18446744073709486085 Cannot enable interface hsi0. interface hsi0 is not up - I will go through the steps in the hipersocket configuration instructions again. Maybe it's not enough to define it in YAST.. Regards/Med vennlig hilsen Roger Evans Autodata Norge A/S On Mon, 2011-11-07 at 10:06 +0100, Ursula Braun wrote: > On Fri, 2011-11-04 at 15:18 +0200, Roger Evans wrote: > > Hi Sue > > > > Didn't seem to help. When booting with SLES10v2 I see the following > > when watching the boot from VM: > > - > > eth: IPv6 not supported on hsi0 > > qeth: Broadcast enabled > > qeth: Using SW checksumming on hsi0. > > qeth: Outbound TSO not supported on hsi0 > > operand exception: 0015 ¬Æ1| > > CPU: 0 Not tainted > > Process hwup-qeth (pid: 709, task: 0f400048, ksp: > > 0eee3960) > > Krnl PSW : 070400018000 1098cefa (do_QDIO+0x452/0x2a9c > > ¬qdio|) > > Krnl GPRS: 0001 00010006 8000 > > 8000 > > 00010006 000f > > 0e931000 0e4cf000 0e931000 > > 1097f000 10994960 0eee3ba8 0eee3aa8 > > Krnl Code: b2 22 00 30 88 30 00 1c 12 33 a7 84 00 0c bf 4f 92 50 a7 84 > > Call Trace: > > (¬<10b03a68>| qeth_dbf_setup+0x0/0xfffe7ad0 ¬qeth|) > > ¬<10adeafc>| __qeth_set_online+0x2780/0x2de4 ¬qeth| > > ¬<1081b544>| ccwgroup_online_store+0x10c/0x1fc ¬ccwgroup| > > ¬<002c43a0>| sysfs_write_file+0x120/0x190 > > ¬<002250f8>| sys_write+0x188/0x38c > > ¬<00115d10>| sysc_noemu+0x10/0x16 > > ¬<021c8738>| 0x21c8738 > > ..done > > Loading required kernel modules > > ¬1A..done<6>device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: > > dm-devel > > ... > > -- > > > > I get this regardless of whether QIOASSIST is ON or OFF. > > > > Regards/ > > Med vennlig hilsen > > > > > > Roger Evans > > > Roger, > > the HiperSockets issue after HW upgrade requires a Linux upgrade: > - see Novell bugzilla 659101 for SLES11 SP1 > - see Novell bugzilla 662984 for SLES10 SP4 > - RHEL 5.7 > - RHEL 6.1 > > Description: qdio: use proper QEBSM operand for SIGA-R and SIGA-S > Symptom: Operand exception leading to kernel panic. > Problem: Wrong SIGA operand on QEBSM enabled qdio devices. > Solution:Use proper SIGA operands in QEBSM mode. > > Switching QIOASSIST OFF for HiperSockets Devices should circumvent the > problem. > > Regards, Ursula Braun, IBM Germany > > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > -- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: hipersockets don't come up after HW upgrade
On Fri, 2011-11-04 at 15:18 +0200, Roger Evans wrote: > Hi Sue > > Didn't seem to help. When booting with SLES10v2 I see the following > when watching the boot from VM: > - > eth: IPv6 not supported on hsi0 > qeth: Broadcast enabled > qeth: Using SW checksumming on hsi0. > qeth: Outbound TSO not supported on hsi0 > operand exception: 0015 ¬Æ1| > CPU: 0 Not tainted > Process hwup-qeth (pid: 709, task: 0f400048, ksp: > 0eee3960) > Krnl PSW : 070400018000 1098cefa (do_QDIO+0x452/0x2a9c > ¬qdio|) > Krnl GPRS: 0001 00010006 8000 > 8000 > 00010006 000f > 0e931000 0e4cf000 0e931000 > 1097f000 10994960 0eee3ba8 0eee3aa8 > Krnl Code: b2 22 00 30 88 30 00 1c 12 33 a7 84 00 0c bf 4f 92 50 a7 84 > Call Trace: > (¬<10b03a68>| qeth_dbf_setup+0x0/0xfffe7ad0 ¬qeth|) > ¬<10adeafc>| __qeth_set_online+0x2780/0x2de4 ¬qeth| > ¬<1081b544>| ccwgroup_online_store+0x10c/0x1fc ¬ccwgroup| > ¬<002c43a0>| sysfs_write_file+0x120/0x190 > ¬<002250f8>| sys_write+0x188/0x38c > ¬<00115d10>| sysc_noemu+0x10/0x16 > ¬<021c8738>| 0x21c8738 > ..done > Loading required kernel modules > ¬1A..done<6>device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: > dm-devel > ... > -- > > I get this regardless of whether QIOASSIST is ON or OFF. > > Regards/ > Med vennlig hilsen > > > Roger Evans > Roger, the HiperSockets issue after HW upgrade requires a Linux upgrade: - see Novell bugzilla 659101 for SLES11 SP1 - see Novell bugzilla 662984 for SLES10 SP4 - RHEL 5.7 - RHEL 6.1 Description: qdio: use proper QEBSM operand for SIGA-R and SIGA-S Symptom: Operand exception leading to kernel panic. Problem: Wrong SIGA operand on QEBSM enabled qdio devices. Solution:Use proper SIGA operands in QEBSM mode. Switching QIOASSIST OFF for HiperSockets Devices should circumvent the problem. Regards, Ursula Braun, IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
