I'm having a problem with the CTC driver that is part of 2.4.19. The
version information that gets put into the kernel ring buffer is "CTC driver
Version: 1.55.10.2 with CHANDEV support initialized."
The problem is that I have both a CTC and ESCON channel pair coupled to
another VM guest, but only one of the pairs is being recognized, and it is
always the _last_ pair defined in /etc/chandev.conf, and it is always
recognized as ctc0. Specifying "noauto" in /etc/chandev.conf does not seem
to help. /proc/chandev shows things are being recognized properly by the
kernel.
/etc/chandev.conf
noauto,0x0600,0x0701
escon0,0x0701,0x0700
ctc0,0x0601,0x0600
The only other message the driver puts out is this:
ctc0: read: ch 0601 (irq 000c), write: ch 0600 (irq 000b) proto: 0
Or, if escon0 is listed last in /etc/chandev.conf, then this:
ctc0: read: ch 0701 (irq 000e), write: ch 0700 (irq 000d) proto: 0
# 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
============================================================================
==
0x02 0x3088 0x1e * * 0 no no
not_operational,no_path,revalidate,device_gone
0x20 0x3088 0x61 * * 0 no no
not_operational,no_path,revalidate,device_gone
0x08 0x3088 0x62 * * 0 no no
not_operational,no_path,revalidate,device_gone
0x10 0x1731 0x05 0x1732 0x05 0 no no
not_operational,no_path,revalidate,device_gone
0x10 0x1731 0x01 0x1732 0x01 0 no no
not_operational,no_path,revalidate,device_gone
0x04 0x3088 0x60 * * 1 no no
not_operational,no_path,revalidate,device_gone
0x06 0x3088 0x1f * * 15 no no
not_operational,no_path,revalidate,device_gone
0x05 0x3088 0x08 * * 15 no no
not_operational,no_path,revalidate,device_gone
0x04 0x3088 0x01 * * 15 no no
not_operational,no_path,revalidate,device_gone
No auto devno ranges
From To
====================
0x0600 0x0701
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 0x0601 0x0600 0x0000 default 0 0 0
0x02 0 0x0701 0x0700 0x0000 default 0 0 0
Registered probe functions
probefunc shutdownfunc msck_notfunc chan devices devices
type found active
===============================================================
0x0484764c 0x04847194 0x048473e4 0x03 1 1
Initialised Devices
read write data read write data chan port dev dev
memory read msck write msck data msck
irq irq irq devno devno devno type no. ptr name
usage(k) status status status
============================================================================
=========================================
0x000c 0x000b n/a 0x0601 0x0600 n/a 0x01 0 0x0168be00 ctc0
n/a good good not applicable
Total device memory usage 0k.
channels detected
chan cu cu dev dev in
chandev
irq devno type type model type model pim chpids use
reg.
============================================================================
===
0x0006 0x1e4a 0x20 0x3088 0x61 0x0000 0x00 0x80 0x6900000000000000 yes
no
0x0007 0x1e4b 0x20 0x3088 0x61 0x0000 0x00 0x80 0x6900000000000000 yes
no
0x000b 0x0600 0x05 0x3088 0x08 0x0000 0x00 0x80 0x0100000000000000 yes
yes
0x000c 0x0601 0x05 0x3088 0x08 0x0000 0x00 0x80 0x0100000000000000 yes
yes
0x000d 0x0700 0x06 0x3088 0x1f 0x0000 0x00 0x80 0x0100000000000000 yes
yes
0x000e 0x0701 0x06 0x3088 0x1f 0x0000 0x00 0x80 0x0100000000000000 yes
yes
0x000f 0x0800 0x10 0x1731 0x05 0x1732 0x05 0x80 0x0300000000000000 no
no
0x0010 0x0801 0x10 0x1731 0x05 0x1732 0x05 0x80 0x0300000000000000 no
no
0x0011 0x0802 0x10 0x1731 0x05 0x1732 0x05 0x80 0x0300000000000000 no
no
Obviously, I have the exact same configuration on the other side of the
channels, but that system is a 2.2.20 kernel without chandev support, and it
works properly.
Mark Post
