Tom, Like I said, it was a stupid, but necessary question. Sigh. It's a lot easier dealing with mistakes than figuring out new problems. :)
I got an off-list email informing me that IBM has a new version of the patch that tries to be more "intelligent" and turn jiffies off only when the system is idling. Do you happen to know if the patch you put on is that version, or the older version? You might be able to discern that from the readme file that came with the patch. I can't say I'll have any advice to offer if it is the newer version, but perhaps the IBM guys would be willing to work with you to figure out what's going on. Mark Post -----Original Message----- From: Geyer, Thomas L. [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 5:38 PM To: [EMAIL PROTECTED] Subject: FW: Pop Timer Patch Mark, The original boot files were in /boot/k_deflt with a symbolic link from kernel -> k_deflt. I copied the new boot files to /boot/k_test then removed the symbolic link and created a new symbolic link, kernel -> k_test. Then re-ran zipl and re-IPLed. Tom -----Original Message----- From: Post, Mark K [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 4:45 PM To: [EMAIL PROTECTED] Subject: Re: Pop Timer Patch Stupid question, but it's gotta be asked... You did copy the kernel to /boot, updated /etc/zipl.conf, re-ran zipl, and re-IPLed didn't you? Mark Post -----Original Message----- From: Geyer, Thomas L. [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 4:30 PM To: [EMAIL PROTECTED] Subject: FW: Pop Timer Patch > I hate to be a pain, but I have installed the pop timer patch (I thought) > when I created the 2.4.17 kernel. I started with SLES 7 which I received > from SuSE as a Trial Copy. I applied the patches in the order specified on > the developerworks website and followed the procedure to rebuild the > kernel. I selected the CONFIG_NO_IDLE_HZ_TIMER option in menuconfig. The > following is a section of the .config file that tells me that it is set: > > CONFIG_PFAULT=y > # CONFIG_SHARED_KERNEL is not set > CONFIG_NO_IDLE_HZ_TIMER=y > > # > # SCSI support > # > CONFIG_SCSI=m > CONFIG_BLK_DEV_SD=m > > I am told that the following data from ESAMAP indicates that the Linux > virtual machine, linuxvm, never leaves the dispatch list. > UserID Logged Non- Disc- Total Tran <-------Dispatch > List-------> > /Class on Idle Active conn InQue /min Q0 Q1 Q2 Q3 > Ldng > -------- ------ ----- ------- ------ ----- ---- ----- ----- ----- ----- > ----- > LINUXVM 1.0 1 1.0 1 0.9 0 0.9 0 0 0 > 0 > > We are still seeing high CPU utilization from this virtual machine with it > doing no productive work. It is consistly in the top 15 cpu users on the > system. > > Below are the patches and the sequence they were applied to build the > kernel: > > tar -xvf /home/geyer/linux-2.4.17.tar > tar -xvf /home/geyer/linux-2.4.17-s390-may2002.tar > patch -p1 -d linux < linux-2.4.17-s390-may2002.diff > tar -zxvf /home/geyer/linux-2.4.17-s390-1-may2002.tar.gz > patch -p1 -d linux < linux-2.4.17-s390-1-may2002.diff > tar -zxvf /home/geyer/linux-2.4.17-timer-1-may2002.tar.gz > patch -p1 -d linux < linux-2.4.17-timer-1-may2002.diff > > > Any suggestions would be greatly appreciated. > > Thanks in advance > > > Tom > > ********************************************************************** This message and any attachments are intended for the individual or entity named above. If you are not the intended recipient, please do not forward, copy, print, use or disclose this communication to others; also please notify the sender by replying to this message, and then delete it from your system. The Timken Company **********************************************************************
