Re: SLES10 Install
I don't think it's related to reiserfs versus ext3. The YaST panels are a little ambiguous when it comes to using the term formatting. The panel where you activate and format your disks is equivalent to varying them online, and then running the dasdfmt command. The panel where you create partitions and set the file system types is equivalent to the fdasd and mkfs commands. You need all of these for things to work. I've had no problems (while using YaST) activating DASD devices, partitioning them, and setting the file system types to ext3. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schilla Sent: Friday, August 18, 2006 5:30 PM To: LINUX-390@VM.MARIST.EDU Subject: FW: SLES10 Install We got the SLES10 install to work. We did the format at the activate DASD screen. When we got to the partitioning screen we created our mount points and left the files system as ReiserFS. This worked. We think our format error occured when we tried changing the ReiserFS to EXT3. Our VDISK swap still does not work but we will try to work thru this. In any cse we are installed and can begin looking at what SLES10 provides. Thanks Everyone, Al Schilla Systems Programmer Enterprise Technology Services Office of Enterprise Technology phone: 651-201-1216 email: [EMAIL PROTECTED] -Original Message- From: Alan Schilla Sent: Thursday, August 17, 2006 3:01 PM To: 'Linux-390 Linux' Subject: FW: SLES10 Install No, we did the activate, paged ahead and then we tried formatting when we created the partitions and selected the software packages. This is the format that fails. We will try this earlier format and see what happens. Thanks, Al Schilla Systems Programmer Enterprise Technology Services Office of Enterprise Technology phone: 651-201-1216 email: [EMAIL PROTECTED] -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Post, Mark K Sent: Thursday, August 17, 2006 1:28 PM To: LINUX-390@vm.marist.edu Subject: Re: SLES10 Install You don't state it explicitly, so I'll ask. Once you activated the DASD volumes you wanted to use, did you (on that same YaST screen) also format them? The drop-down list has three options (if I'm remembering right): Activate Deactivate Format Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schilla Sent: Wednesday, August 16, 2006 4:11 PM To: LINUX-390@VM.MARIST.EDU Subject: Re: SLES10 Install We are trying the install of sles10 and get the boot loader and thru the network config to the FTP server for installation. We connect to the new guest via cygwin and ssh. We start the configuration of the disk partitions and select software and when we continue to where the install process would generally format the dasd we receive the following messages: Failure occurred during following action: Executing fdasd for disk /dev/dasdb... System error code was: -11001 /sbin/fdasd -c /tmp/liby2storageIT5Z1N/fdasd_inp /dev/dasdb: fdasd error: Unsupported disk format /dev/dasdb is not formatted with z/OS compatible disk layout Has anyone else experienced this error? Thanks, Al Schilla Systems Programmer Enterprise Technology Services Office of Enterprise Technology phone: 651-201-1216 email: [EMAIL PROTECTED] -Original Message- From: Alan Schilla Sent: Friday, August 11, 2006 9:03 AM To: 'Linux-390 Linux' Subject: FW: SLES10 Install Thanks to everyone who has responded. I will use the suggested paths to CD images. It seems very straight-forward. I will also test the install process to a VLAN guest and see what happens. I will post back if I encounter any errors or problems. Thanks for Your Help, Al Schilla Systems Programmer Enterprise Technology Services Office of Enterprise Technology phone: 651-201-1216 email: [EMAIL PROTECTED] -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Nix, Robert P. Sent: Thursday, August 10, 2006 3:48 PM To: LINUX-390@vm.marist.edu Subject: Re: SLES10 Install Our initial test, we had to copy all the CDs into a common disk directory, and point to that directory via FTP. We've since downloaded the DVD, and will just mount that and point to it for our next attempt at SLES 10. There's no fancy SLES10/CD1 and CD2 stuff; just copy all the CDs (probably CD number 1 last, so that all of the checksums are correct) to a single directory, and give it a shot. -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13 200 First Street SW /( )\ 507-284-0844Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Schilla Sent: Thursday, August 10, 2006 8:54 AM To: LINUX-390@VM.MARIST.EDU Subject: SLES10 Install We are beginning to look at the
Re: zLinux VIPA setup.
Jim, please check and/or show us your quagga.log file for any relevant errors. Mark -- 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
Tracing question
Please forgive the naivety of this question, but my knowledge of Linux is severely limited. Back in the good old days of VM and CMS, it was easy to load a program, locate it in storage, set a few CP trace traps within it, and then start it running. How can I do the same thing in Linux? Specifically, I'd like to be able to trace the entire execution of a given program running under Linux, but I have less than a clue as to how to do that. Many thanks... Ray Mansell -- 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
Re: zLinux VIPA setup.
Here is the quagga.log, Thanks for looking at it. I can't understand why I'm getting the MTU errors.All other MTUs that I could check are set at 1400, as is linux. for reference. 185 is the vipa interface, the 51s are the eth interfaces connected through vswitches to OSA cards. linux-00:/var/log/quagga # cat quagga.log 2006/08/21 08:39:21 OSPF: interface 10.115.20.185 join AllSPFRouters Multicast group. 2006/08/21 08:39:21 OSPF: interface 10.115.136.51 join AllSPFRouters Multicast group. 2006/08/21 08:39:21 OSPF: interface 10.115.137.51 join AllSPFRouters Multicast group. 2006/08/21 08:39:22 OSPF: Packet[DD]: MTU is larger than [eth0:10.115.136.51]'s MTU 2006/08/21 08:39:23 OSPF: DR-Election[1st]: Backup 10.115.136.31 2006/08/21 08:39:23 OSPF: DR-Election[1st]: DR 10.115.136.31 2006/08/21 08:39:23 OSPF: DR-Election[1st]: Backup 0.0.0.0 2006/08/21 08:39:23 OSPF: DR-Election[1st]: DR 0.0.0.0 2006/08/21 08:39:23 OSPF: DR-Election[1st]: Backup 0.0.0.0 2006/08/21 08:39:23 OSPF: DR-Election[1st]: DR 0.0.0.0 2006/08/21 08:39:23 OSPF: DR-Election[1st]: Backup 10.115.136.30 2006/08/21 08:39:23 OSPF: DR-Election[1st]: DR 10.115.136.30 2006/08/21 08:39:23 OSPF: DR-Election[1st]: Backup 0.0.0.0 2006/08/21 08:39:23 OSPF: DR-Election[1st]: DR 0.0.0.0 2006/08/21 08:39:23 OSPF: DR-Election[1st]: Backup 0.0.0.0 2006/08/21 08:39:23 OSPF: DR-Election[1st]: DR 0.0.0.0 2006/08/21 08:39:27 OSPF: Packet[DD]: MTU is larger than [eth0:10.115.136.51]'s MTU 2006/08/21 08:39:30 OSPF: DR-Election[1st]: Backup 10.115.137.1 2006/08/21 08:39:30 OSPF: DR-Election[1st]: DR 10.115.137.1 2006/08/21 08:39:30 OSPF: DR-Election[1st]: Backup 0.0.0.0 2006/08/21 08:39:30 OSPF: DR-Election[1st]: DR 10.115.137.1 2006/08/21 08:39:30 OSPF: Packet[DD]: MTU is larger than [eth1:10.115.137.51]'s MTU 2006/08/21 08:39:31 OSPF: DR-Election[1st]: Backup 0.0.0.0 2006/08/21 08:39:31 OSPF: DR-Election[1st]: DR 10.115.136.1 2006/08/21 08:39:32 OSPF: Packet[DD]: MTU is larger than [eth0:10.115.136.51]'s MTU 2006/08/21 08:39:33 OSPF: DR-Election[1st]: Backup 0.0.0.0 2006/08/21 08:39:33 OSPF: DR-Election[1st]: DR 10.115.137.1 2006/08/21 08:39:33 OSPF: DR-Election[1st]: Backup 0.0.0.0 2006/08/21 08:39:33 OSPF: DR-Election[1st]: DR 10.115.137.1 2006/08/21 08:39:35 OSPF: Packet[DD]: MTU is larger than [eth1:10.115.137.51]'s MTU 2006/08/21 08:39:37 OSPF: Packet[DD]: MTU is larger than [eth0:10.115.136.51]'s MTU 2006/08/21 08:39:40 OSPF: Packet[DD]: MTU is larger than [eth1:10.115.137.51]'s MTU 2006/08/21 08:39:42 OSPF: Packet[DD]: MTU is larger than [eth0:10.115.136.51]'s MTU 2006/08/21 08:39:45 OSPF: Packet[DD]: MTU is larger than [eth1:10.115.137.51]'s MTU 2006/08/21 08:39:47 OSPF: Packet[DD]: MTU is larger than [eth0:10.115.136.51]'s MTU 2006/08/21 08:39:50 OSPF: Packet[DD]: MTU is larger than [eth1:10.115.137.51]'s MTU 2006/08/21 08:39:52 OSPF: Packet[DD]: MTU is larger than [eth0:10.115.136.51]'s MTU 2006/08/2 Jim Barnett United Health Technologies Mainframe Systems Mark Perry [EMAIL PROTECTED] Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU 08/21/2006 02:56 AM Please respond to Linux on 390 Port LINUX-390@VM.MARIST.EDU To LINUX-390@VM.MARIST.EDU cc Subject Re: zLinux VIPA setup. Jim, please check and/or show us your quagga.log file for any relevant errors. Mark -- 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 This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -- 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
Re: Tracing question
-Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Ray Mansell Sent: Monday, August 21, 2006 9:23 AM To: LINUX-390@VM.MARIST.EDU Subject: Tracing question Please forgive the naivety of this question, but my knowledge of Linux is severely limited. Back in the good old days of VM and CMS, it was easy to load a program, locate it in storage, set a few CP trace traps within it, and then start it running. How can I do the same thing in Linux? Specifically, I'd like to be able to trace the entire execution of a given program running under Linux, but I have less than a clue as to how to do that. Many thanks... Ray Mansell GDB - The GNU Debugger. It use the ptrace function in Linux to do these things. It is also a source level debugger if you compiled the program with the -g switch. If you just want to see what system calls the program issued, then use the strace command. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- 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
Re: Tracing question
Ar Llu, 2006-08-21 am 10:23 -0400, ysgrifennodd Ray Mansell: Please forgive the naivety of this question, but my knowledge of Linux is severely limited. Back in the good old days of VM and CMS, it was easy to load a program, locate it in storage, set a few CP trace traps within it, and then start it running. How can I do the same thing in Linux? Specifically, I'd like to be able to trace the entire execution of a given program running under Linux, but I have less than a clue as to how to do that. The low level interface is ptrace (2) (see man 2 ptrace). Usually people deal with things at a higher level and the gdb debugger can do tracing and trapping of the application including things like run into variable X is set. For what is going on type events there are tools called strace and ltrace which trace system calls and library calls respectively. Alan -- 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
/dev/random
Hi, I tried to use gpg today to generate a pgp key on SLES9x. The process hangs while reading from /dev/random (which is lacking entropy). Hasn't this whole /dev/random (and /dev/urandom) thing been beaten to death? Does anyone else use gpg on s390x? Cheers, Arty -- 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
Re: Tracing question
Hi, Ray gdb will give you an instruction trace. Use the gdb command display/i $pc and then use either si or ni to step instructionwise through your program. Richard Hitt[EMAIL PROTECTED] Ray Mansell wrote: Thank you both for the responses, but this isn't quite what I'm after. I really do need a CP instruction trace of a given program running in Linux, and as far as I can tell, neither gdb nor ptrace will give me this. Thanks again, Ray Alan Cox wrote: Ar Llu, 2006-08-21 am 10:23 -0400, ysgrifennodd Ray Mansell: The low level interface is ptrace (2) (see man 2 ptrace). McKown, John wrote: GDB - The GNU Debugger. It use the ptrace function in Linux to do these things. It is also a source level debugger if you compiled the program with the -g switch. -- 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 -- 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
Re: Tracing question
Thank you both for the responses, but this isn't quite what I'm after. I really do need a CP instruction trace of a given program running in Linux, and as far as I can tell, neither gdb nor ptrace will give me this. Thanks again, Ray Alan Cox wrote: Ar Llu, 2006-08-21 am 10:23 -0400, ysgrifennodd Ray Mansell: The low level interface is ptrace (2) (see man 2 ptrace). McKown, John wrote: GDB - The GNU Debugger. It use the ptrace function in Linux to do these things. It is also a source level debugger if you compiled the program with the -g switch. -- 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
Re: Tracing question
Use gdb to stop the program where you are interested. Get its address. Quit gdb. Go to the VM console: #CP TR I R address of the routine you are interested in (If you are in a virtual MP environment then prefix commands by #CP CPU ALL, e.g. #CP CPU ALL TR I R ...) Start the program. When you the trace springs then: #CP D Iaddress of routine). Find the exit of the routine (BR R15 or BR R4). Note the address. Then: #CP TR END#TR I R start-end PRINT#TR G R start-end PRINT#B When you are done: #CP TR END#SP P MAINT CLOSE NAME LINUX TRACE -Original Message- Thank you both for the responses, but this isn't quite what I'm after. I really do need a CP instruction trace of a given program running in Linux, and as far as I can tell, neither gdb nor ptrace will give me this. -- 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
Re: /dev/random
I haven't done it on s390x, just on s390, also on SLES8, I believe. Had no problems. Tom Duerbusch THD Consulting [EMAIL PROTECTED] 8/21/2006 1:08 PM Hi, I tried to use gpg today to generate a pgp key on SLES9x. The process hangs while reading from /dev/random (which is lacking entropy). Hasn't this whole /dev/random (and /dev/urandom) thing been beaten to death? Does anyone else use gpg on s390x? Cheers, Arty -- 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 -- 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
Re: Tracing question
Ar Llu, 2006-08-21 am 12:28 -0400, ysgrifennodd Ray Mansell: Thank you both for the responses, but this isn't quite what I'm after. I really do need a CP instruction trace of a given program running in Linux, and as far as I can tell, neither gdb nor ptrace will give me this. They won't. Linux is designed to stand alone so debugging is done within Linux (even for kernel tracing with kprobes, systemtap). Its difficult to see how else you would do it as user space code changes mappings regularly so you'd note have enough information below Linux to track much Alan -- 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
Re: Tracing question
Gentlemen, Many thanks... I think I have it now. Much appreciated... Ray Richard Hitt wrote: Hi, Ray gdb will give you an instruction trace. Use the gdb command display/i $pc and then use either si or ni to step instructionwise through your program. Neale Ferguson wrote: Use gdb to stop the program where you are interested. Get its address. Quit gdb. Go to the VM console: -- 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
Re: Vendor's Matter
On Saturday, 08/19/2006 at 08:20 ZE2, Waite, Dick [EMAIL PROTECTED] wrote: I would agree with Marcy, vendor's matter. We switched last weekend from z/VM 5.1 to 5.2 and all my Linux machines running SuSE SLE 10.0 stopped working (I/O errors). They are all SCSI attached. You might remember my post. Well we do NOT have IBM SCSI and so far we are still running with the bypass of switching of QIOASSIST. I'm told by wise people that this is working grand on IBM SCSI... The QDIO Assist has nothing to do with the type of SCSI device (and, by inference, the SCSI payload). Instead, it deals with the structures that manage the payloads. So, this means that there is a relationship between the way the device driver creates said structures and the hardware itself (in the form of the assist). Further, CP has to create inputs that allow the assist to work. If you changed only z/VM, and turning off the assist gets everything working again, then there are only two possibilities: 1. The assist itself is broken 2. CP's management of the assist is broken Use of non-IBM devices may result in changes to the timing of events, surfacing defects not previously observed. Either way, the correct response to the issue is a PMR. (And I think one has been opened.) Alan Altmark z/VM Development IBM Endicott -- 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
Re: Vendors Matter
Right, function is one thing, performance is something else. It may work, but not work well. What I think Rick and friends need to do is to ask EMC to investigate it. They can analyze it and make pretty graphs. Ask them specifically if you are seeing any device level write pendings. RAID configuration affects that as well as the applications i/o sizes and patterns. Not all performance problems can be found by tools such as Velocity PTK which will look at the VM and Linux level. Sometimes your problem is at a lower level. Marcy Cortes This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 21, 2006 13:55 To: LINUX-390@VM.MARIST.EDU Subject: Re: [LINUX-390] Vendor's Matter On Saturday, 08/19/2006 at 08:20 ZE2, Waite, Dick [EMAIL PROTECTED] wrote: I would agree with Marcy, vendor's matter. We switched last weekend from z/VM 5.1 to 5.2 and all my Linux machines running SuSE SLE 10.0 stopped working (I/O errors). They are all SCSI attached. You might remember my post. Well we do NOT have IBM SCSI and so far we are still running with the bypass of switching of QIOASSIST. I'm told by wise people that this is working grand on IBM SCSI... The QDIO Assist has nothing to do with the type of SCSI device (and, by inference, the SCSI payload). Instead, it deals with the structures that manage the payloads. So, this means that there is a relationship between the way the device driver creates said structures and the hardware itself (in the form of the assist). Further, CP has to create inputs that allow the assist to work. If you changed only z/VM, and turning off the assist gets everything working again, then there are only two possibilities: 1. The assist itself is broken 2. CP's management of the assist is broken Use of non-IBM devices may result in changes to the timing of events, surfacing defects not previously observed. Either way, the correct response to the issue is a PMR. (And I think one has been opened.) Alan Altmark z/VM Development IBM Endicott -- 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 -- 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
Re: /dev/random
Not specifically, but I just checked one of my SLES9 SP3 s390x systems: # cat /proc/sys/kernel/random/entropy_avail 2944 My system is fairly idle. What are you running on your system? Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Arty Ecock Sent: Monday, August 21, 2006 2:08 PM To: LINUX-390@VM.MARIST.EDU Subject: /dev/random Hi, I tried to use gpg today to generate a pgp key on SLES9x. The process hangs while reading from /dev/random (which is lacking entropy). Hasn't this whole /dev/random (and /dev/urandom) thing been beaten to death? Does anyone else use gpg on s390x? Cheers, Arty -- 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
Re: /dev/random
I was never able to generate GPG or ssh public/private personal keys because of the lack of entropy on my basically idle system. I had to generate all of the personal keys down on my PC and upload them for use under Linux or z/OS. /Tom Kern --- Arty Ecock [EMAIL PROTECTED] wrote: Hi, I tried to use gpg today to generate a pgp key on SLES9x. The process hangs while reading from /dev/random (which is lacking entropy). Hasn't this whole /dev/random (and /dev/urandom) thing been beaten to death? Does anyone else use gpg on s390x? Cheers, Arty -- 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- 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
Re: /dev/random
Hi, On Mon, 21 Aug 2006 18:58:38 -0400 Post, Mark K said: Not specifically, but I just checked one of my SLES9 SP3 s390x systems: # cat /proc/sys/kernel/random/entropy_avail 2944 My system is fairly idle. What are you running on your system?=20 My guest is very very idle. The z990 is somewhat large. entropy_avail = 355 Cheers, Arty -- 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
