Michael, I'll tell you what I tell everyone when the "quick fixes" don't work. To figure out what's going wrong, you need to do it all manually. The startup scripts hide any error messages that might get generated during system startup, and all you get is that "OK" message. So, start by making sure that your ctc module (you _do_ have it defined as a module, based on what you're saying?) is unloaded: lsmod If it shows up, then: rmmod ctc If you do a "dmesg | tail" command you should see something like this: CTC driver unloaded Now, load it again, and watch for any error messages insmod ctc Again, if you do a "dmesg | tail" you should see something like this: CTC driver Version: 1.51 initialized ctc0: read: ch 0f00 (irq 0003), write: ch 0f01 (irq 0004) proto: 0 This is what I have in my kernel parameter file: # cat parmfile root=/dev/dasda1 dasd=301,300,302-30f chandev=ctc0,0x0f00,0x0f01 Make sure that you have your read-write pairs "crossed" so that you don't have a read channel connected to the other side's read channel, etc. Make sure your CTCs are being detected by the system properly: # cat subchannels Device sch. Dev Type/Model CU in use PIM PAM POM LPUM CHPIDs -------------------------------------------------------------------------- 0300 0000 3390/0A 3990/E9 yes FC FC FF 80 1E252C6C 7380FFFF 0301 0001 3390/0A 3990/E9 yes FC FC FF 80 1E252C6C 7380FFFF 0302 0002 3390/0A 3990/E9 yes FC FC FF 80 1E252C6C 7380FFFF 0F00 0003 3088/08 yes 80 80 FF 80 FB000000 00000000 0F01 0004 3088/08 yes 80 80 FF 80 FB000000 00000000 # cat chandev chan_type key bitfield ctc=0x1,escon=0x2,lcs=0x4,osad=0x8,qeth=0x10,claw=0x20 *'s for cu/dev type/models indicate don't cares cautious_auto_detect: on persist = 0x00 use_devno_names: off Channels enabled for detection chan cu cu dev dev max checksum use hw auto recovery type type model type model port_no. received stats type ============================================================================ == -snip- Forced devices chan defif read write data memory port ip hw host adapter api type num devno devno devno usage(k) protocol no. chksum stats name name name ============================================================================ =================== 0x01 0 0x0f00 0x0f01 0x0000 default 0 0 0 Mark Post -----Original Message----- From: Michael K Lambert [mailto:mlambe7@lsu.edu] Sent: Friday, December 21, 2001 10:26 AM To: redhat-s390-list@redhat.com Subject: [Redhat-s390-list] X-mas wishes All I want for Christmas is a fully functioning CTC connection :) Seriously, I'd like to thank everyone here for their extreme patience when faced with my incessant questions. You have my word that as soon as I get this CTC connection up, I will stop spamming this list and you can get back to whatever holiday celebrations that you observe. I've placed a ctc config file in the appropriate places (/etc/sysconfig/networking-scripts/, etc), aliased it in modules.conf (alias ctc0 ctc) and inserted a channel definition in my parmfile (chandev=ctc0,0x2000,0x2001). At ipl, interface ctc0 initializes ok, but I can't see it when I ifconfig -a. This is the same situation that I was initially in wiht IUCV, so I'm sure that I'm missing some minor piece of the puzzle. I've searched the archives of this and the Marist list, but I've found different, sometimes conflicting, advice. As usual, if anyone could point me in the right direction, I would be grateful. Michael Lambert _______________________________________________ Redhat-s390-list mailing list Redhat-s390-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-s390-list