Re: RE : tape3590 SLES7
On Mon, 8 Dec 2003, Monteleone wrote: Hello Mark, Thanks for your response, I think my problem is born after applying the K_timer-2.4.7-9 package on my SLES7. I think the new generic module tape390.o brought with this package don't load any external module. The k_timer-2.4.7-9 rpm is from May 21, 2002. I can see that it does not have the functions which your modprobe complains about, these are needed to support a separate tape3590 module and it appears that tape3590 did no appear before 2003-02-20. I think the only solution is to run a newer kernel, you should anyway, because of a security issue which became known this summer. Bernhard linsvg:( ? T390:IBM S/390 Tape Device Driver (v1.01). T390:(C) IBM Deutschland Entwicklung GmbH, 2000 T390:character device frontend : built in T390:block device frontend : built in T390:support for 3480 compatible : built in T390:support for 3490 compatible : built in
Re: hz_timer
On Tue, 10 Jun 2003, Tom Duerbusch wrote: I set it to '0' as suggested for VM types. But after a boot, it is back to '1'. The documentation on this doesn't say anything about needing to put it in a boot script. Seems to imply that this is a one time only thing. ... 3. Is the docs wrong and I do have to put it in a boot script? There is already a script, it configure it, take these steps: 1) Create/Update the sysctl config file, e.g. by: # echo kernel.hz_timer=0 /etc/sysctl.conf Verify and activate the current config in /etc/sysctl.conf: # sysctl -p If successful, it prints: kernel.hz_timer = 0 2) Activate the boot service to call sysctl -p at boot: chkconfig -a boot.sysctl (ignore the output in this case) Which creates a symlink to boot.sysctl in /etc/init.d/boot.d/ 3/Test) After the next reboot, # sysctl kernel.hz_timer should print: kernel.hz_timer = 0 Bernhard Kaindl
Re: SLES8 dasdfmt problem
On Wed, 4 Jun 2003, Dave Myers wrote: Well our ramacs are not working. There is no dasd or 3990 info in /proc/subchannels after the dasd is loaded from yast. The contents of /proc/subchannels should not change unless something to the hardware I/O changes, there should be also no 3990 info then before you start yast, e.g. when you select No network at the first menu. As long there is no line containing the dasd device and control unit type in /proc/subchannels, no rmmod, modprobes, no dasd driver, no yast, no mkmod can change anything, the dasd driver is given nothing by the I/O subsystem which it could handle, thus the status unknown. This is a more lower level issue then. I say S/390 I/O Subsystem - Hardware, cabling, online/offline, IOCDs, Microcode, or Linux S/390 lowlevel I/O code, specifically the subchannel scanning executed at IPL. You could add cio_msg=yes to the kernel parameters when IPLing it for installation and look for the early S/390 HW detection messages then: Detected device ... on subchannel PIM ... PAM ... POM ... (these and around there) Bernd Kaindl /proc/dasd/devices shows the 3380 with an unknown status. No insmods, rmmods modprobes etc. change that symptom. mknod comes back with a message indicating that the 94:0 is already registered..but the linux console messages say otherwise!! I am wondering if 3990-13 might be the problem??? Do you use mod 13 controllers on your ramac?? Dave Myers Denver Solutions Group Senior Systems Engineer Office Phone: (303) 996-7112 Cellular Phone: (303) 619-0782 Home Office: (303) 948-0027 Fax: (303) 706.1713 e-mail: [EMAIL PROTECTED] Tom Duerbusch [EMAIL PROTECTED] To: [EMAIL PROTECTED] scity.com cc: Sent by: Linux onSubject: Re: SLES8 dasdfmt problem 390 Port [EMAIL PROTECTED] ST.EDU 06/04/2003 08:33 AM Please respond to Linux on 390 Port Don't worry about the Ramacs. I have Suse 8 loaded on both 3380 and 3390 Ramac Dasd Subsystems, as well as MP3000 internal dasd. I haven't had to add disk. Mine were added durning installation. I assume that you went to the Suse website. There is a paper on adding S390 dasd to a running Linux system. That worked for me when I added dasd to Linux 7. Tom Duerbusch THD Consulting
Re: RedHat vs Suse
On Thu, 29 May 2003, Tom Duerbusch wrote: My way was and still is, SMB under Windows. But, Sles8 requires Win/98 or above for SMB support. My personal thinking is that M*S dropped support Win95 long years ago, it's no excuse however, but I can't find Win95 anywere near. I assume it should be possible to install from Win95 with special guidiance, but it at least needs a special mount command which you have to do by hand and behind the covers. I'm sorry that I can't say more. Side note: Two years ago I have been told that it's really useful having a Notebook which can take some CDs which has (preferably) Linux Installed and a known to be good SMB/FTP/NFS server running together with good tools for remote login. I think this is still true today if it's not sure which installation servers are available. My apologizes to all for all the installation problems and changes the update from SLES7 to SLES8 brings and I think it should be possible to fill a little book with all the changes. For now, the only thing I can do is to suggest to create a stable installaton environment for such cases which you can take with you and ask for support if you encounter problems with this environment. And having to issue a STOP and START to the TCPIP machine everytime I boot Sles8 is really a pain. CTC was the first connection which worked for VM connectiviy with Linux, but as others also told, IUCV has grown up. It connects instantaneous, you don't have to take care of coupling and don't have to wait for emulated hardware negotiation to complete before you can talk to the other side. The other thing I know is that this type of problem does not happen if the other side of the CTC connection is not VM TCPIP but another Linux guest and if both Linux Guests have the CTC I/O Error retry fix which has been developed at my suggestion by the Linux CTC driver maintainer. It adds a timer which restarts the CTC setup after I/O errors. This fix has been integrated into SLES8 GA and SLES7 maintenance. If you run kernels with this fix on all CTC machines and the router is also a CTC machine with this fix, all CTC machines will properly recover from a reboot on the the other side. I have tested this on a big CTC setup with many guests where we changed the Router of the CTC connection from VM TCPIP to SLES7. The thing was(like in your case) that if one side of the CTC connection is rebooted, it is possible that the other is get's an I/O Error, e.g., if it tries to send a message while the other side is rebooting. Recovery from an I/O Error was not implemented, because an I/O Error was sonsidered as an Hardware error which is not recoverable. Now, without the recovery patch I suggested, if you reported some of the Linux Guests, they sometimes did came back like what I have seen here: It comes up, reports no error but there is no connection. Now, if I looked what happened at the Linux Router side of the CTC connection, I saw an I/O error, which was not recovered as it was thought it is a non-recoverable hardware error. But if you did an ifconfig down and an ifconfig up(to restart the ctc setup manually) for the ctc interface on the Router side, there has been a chance that they reconnected. Of course there was the possibility that the Linux Guest not got an I/O error and you play the recovery game again. I suggested to fix this to do the action which ifconfig down-up causes in the driver on a timed interval if an I/O error occured, and the implemetation of it and install of the fix on both Linux guests of the CTC connection fixed this problem. This looks like to me as if VM TCPIP does not set such recovery timer up to restart the CTC setup on a regular interval if the CTC connection on the VM TCPIP side terminated because of an I/O error which was caused by the Linux Guest reboot. I have no idea why this did not happen with SLES7 in your cases, I see either changes in the hardware setup between the August 2001 code stream which SLES7 is based on and the May 2002 code stream from Developerworks which SLES8 is based or an VM update in combination with this. On a personal note, I also think that using Linux Guest(s) with QETH as Router(s) for Linux Guests are more powerful than using VM TCPIP: VM TCPIP needs less disk space and memory, but on the other side, if you use Linux Guest(s) instead of VM TCPIP for routing, you have some other benefits: - You can implement a redundant two-router failover configuration in which e.g. if something bad happens to one router (Cable pull on the OSA Express card or other Hardware Failure which affects the OSA Express card) the other Router can detect this and automatically take over. This is also nice if you need to do a Micorcode Update or the OSA Express cards which is not concurrent for the card so that you have to vary the card off and on in order to load the new microcode. In this situation the fallback router (even if not setup automatically) comes handy. This is
Re: CPU Arch Security
Hi, I think that I can understand both views, but I can only say that I think the concepts needed to exploit the different execution domains within one process is asking for a new operating system and that I guess this new operating system might be S/390-specific or the applications using it would be specific to S/390, but then the IBM model of having one OS (Linux) for every IBM eServer would not fit for this thing. From the development and testing perspecive it would also be better to work on improving the existing Linux applications and operating system environments to run a normal user, use capabilites, compartments (chrooted environments) and everybody, not only the S/390 server users would benefit.(I want to have the same capabilies on my home server or PDA) Bernd
Re: SuSE Install Question
On Tue, 2 Jul 2002, Dave Myers wrote: Where do I go to get the lastest SuSE for S/390 (freebie, no maint). (is this freebie beta or GA ??) ftp://ftp.suse.com/pub/suse/s390/sles7-beta/31-bit Where are instructions for installing this using an existing Suse S/390 system ?? Mount the disk you want to install to, run yast, Installation settings - Installation to a directory - Enter the path where you mounted the disk. Then from the Main Menu: Package Management - Start installation and leave yast thru the main menu afterwards. umount and detach the disk and IPL it. Before Start installation you can also load/change/save other package selections in the Package Management menu. Bernd
Re: Clear Case
On Mon, 24 Jun 2002, Rick Kissel wrote: Barr Bill P writes: I don't believe it's been ported, yet. If ever. Actually, ClearCase on SuSE Linux 390 has been available for about a year now. It has only been ported to the SuSE distribution, but it's full ClearCase (dynamic views, i.e. mvfs, and all). Great! I just noticed that Version/Availability details can be found at: http://www.rational.com/support/documentation/release/cc_releases.jsp ClearCase, MultiSite, Attache v 2002.05.00 (5.0) UNIX (Reference Release Availability: 11/2001, Full Release Availability: 02/2002 Supported through 02/2004) - ClearCase, MultiSite, Attache v 2002.05.00 (5.0) UNIX (Reference Release Availability: 11/2001, Full Release Availability: 02/2002 Supported through 02/2004) IBM S/390, IBM zSeries SuSE Linux Enterprise Server 7 Kernel 2.4.7 - ClearCase, MultiSite, Attache 4.2 UNIX (Reference Release Availability: 05/2001, Full Release Availability: 07/2001 Supported through 07/2003) IBM S/390, IBM zSeries SuSE Linux 7.0 Kernel 2.2.16 -- Bernd
Re: Process to move to a jfs on an existing system
Strictly speaking, true, but many people had it installed on their 2.2 systems. My point was that I'm not aware of whether or not the endian-safe fixes that went into the official 2.4 tree were retro-fitted into the non-official patches maintained for the 2.2 kernel. Do you know if this has been done or not, or would I need to ask the developer? You'd need to ask the developers and then find out exactly what was added to the various 2.2 vendor trees that support it The big-endian support for reiserfs has been done on the tree for kernel 2.4, to my knowledge, no backport exists. It would be doable, but it's better to go forward and use SLES7 for Reiserfs. Bernd Kaindl
Re: Problem: s390 multiple literalpool support
On Thu, 27 Dec 2001, Holger Smolinski wrote: Folks, I forwarded your question to Uli WEigand and Hartmut Penner They know best about the gcc and its bugs ;) Hi Eric, just as a tip: - this should only show up in very large, computer-generated functions which use a lot of static constants. Most generated functions should be easy to split because they may be just large and with many constants but not with complex code. I can't tell for sure in your case, but splitting the largest function in the file might help. 4k seems to be limit you have to reach(including the data the profiling may add). However, I'd like to have multiple literalpool support as well... Bernd Hi I use gcc version 2.95.2 19991024 (release) from SuSE 7.0 for S390. When compiling with both -pg and -fprofile-arcs I receive this error message: (insn 29697 29698 2 (use:SI (mem/u:SI (symbol_ref/u:SI (*.LC2269)) 0)) -1 (nil) (nil)) (insn 29697 29698 2 (use:SI (mem/u:SI (symbol_ref/u:SI (*.LC2269)) 0)) -1 (nil) (nil)) main/svd3.c: In function `FFOrdTrans': main/svd3.c:1863: s390 multiple literalpool support: No code label between this insn 0 1D009 With only -pg profiling does not seem to work, I get counts on the number of times each function has executed but not the time spent in each function. I only receive this for 3 of maybe 100 source files. Is this problem fixed in a later version of gcc? RegardsErik
