Tom Shilson wrote: > My z/VM wizard returned from share greatly excited to try swapping to > DCSS. He set up the segments and an EXEC that would properly define > storage with the gap. It was up to me to do the Linux part. With only a > few stumbles I got it running. There is one inconsistency. I set up > the zipl.conf parameter to specify dcss.segments=SWAP16M,<more segments> > . The console log says that the dcss.segments= parameter is invalid, > yet it must be there for swapping to DCSS to work. /proc/cmdline shows > the entire parameter string. Here is a snip from the console log: > > Kernel command line: root=/dev/dasdb1 selinux=0 TERM=dumb elevator=cfq > vmpoff=LOGOFF > dcssblk.segments=SWAP16M,SWAP32M,SWAP64M,SWAP128M,SWAP256M,SWAP512M > BOOT_IMAGE=0 > Unknown boot option > `dcssblk.segments=SWAP16M,SWAP32M,SWAP64M,SWAP128M,SWAP256M,SWAP512M': > ignoring > > Here is my zipl.conf parameter string: parameters = > "root=/dev/dasdb1 > selinux=0 TERM=dumb elevator=cfq vmpoff=LOGOFF > dcssblk.segments=SWAP16M,SWAP32M,SWAP64M,SWAP128M,SWAP256M,SWAP512M " > > This is SuSE SLES9 64-bit SP3 recently patched running on z/VM 5.2 on a > z900. > > Can anyone explain it or tell me which organization I should notify? SuSE does not have dcssblk device driver built-in. They do have it as a module. If it is built-in, this parameter is supplied via parmline as you did. Once it is as a module (as it is in Sles), you can specify the very same parameter on module load $bash:[EMAIL PROTECTED]> insmod dcssblk dcssblk.segments=first,second,last
In order to automate that, putting the parameter into /etc/modules.conf automagically adds the parameter to the module whenever it gets loaded. cheers, Carsten -- Carsten Otte IBM Linux technology center ARCH=s390 ---------------------------------------------------------------------- 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
