Description of problem: If ccsd is started before the cman module is loaded you get these messages in the logfile: Jun 30 18:57:58 link-10 kernel: Bluetooth: Core ver 2.5 Jun 30 18:57:58 link-10 kernel: NET: Registered protocol family 31 Jun 30 18:57:58 link-10 kernel: Bluetooth: HCI device and connection manager initialized Jun 30 18:57:58 link-10 kernel: Bluetooth: HCI socket layer initialized Jun 30 18:57:58 link-10 kernel: Bluetooth: L2CAP ver 2.2 Jun 30 18:57:58 link-10 kernel: Bluetooth: L2CAP socket layer initialized Jun 30 18:57:58 link-10 kernel: Bluetooth: RFCOMM ver 1.3 Jun 30 18:57:58 link-10 kernel: Bluetooth: RFCOMM socket layer initialized Jun 30 18:57:58 link-10 kernel: Bluetooth: RFCOMM TTY layer initialized Both bluetooth and ccsd want to NET: register protocol family 31. Shouldn't we have something unique? If you then modprobe the lock_dlm (which pulls in the cman and dlm modules) it fails with unresolved symbols. ccsd is defined in the cluster architecture as not being dependent on anything, so it seems reasonable to start this before loading modules. [root@link-10 /]# modprobe lock_dlm WARNING: Error inserting cman (/lib/modules/2.6.7/kernel/cluster/cman.ko): Operation not permitted WARNING: Error inserting dlm (/lib/modules/2.6.7/kernel/cluster/dlm.ko): Unknown symbol in module, or unknown parameter (see dmesg) FATAL: Error inserting lock_dlm (/lib/modules/2.6.7/kernel/fs/gfs_locking/lock_dlm/lock_dlm.ko): Unknown symbol in module, or unknown parameter (see dmesg) Version-Release number of selected component (if applicable): [root@link-10 /]# ccsd -V ccsd DEVEL.1088629082 (built Jun 30 2004 15:59:04) Copyright (C) Red Hat, Inc. 2004 All rights reserved. How reproducible: Yes. Steps to Reproduce: 1. Boot 2. 'ccsd' 3. 'modprobe lock_dlm' Actual results: Modules do not load Expected results: Modules do load Additional info:
I don't beleive that the socket family chosen for cman should conflict with something else.
adding patrick to cc list
Changed to 30 as this is unused in the stock 2.6 kernel. It's also the number TIPC uses and you're unlikely ever to need both at the same time so this seemed like a good compromise. Checking in cnxman-socket.h; /cvs/cluster/cluster/cman-kernel/src/cnxman-socket.h,v <-- cnxman-socket.h new revision: 1.3; previous revision: 1.2 done
With that change clvmd now cannot connect to cman. The AF_CLUSTER in lvm needs to match (or refer to same header file for this?). lvm2/daemons/clvmd cnxman-socket.h:#define AF_CLUSTER 31
Err....You must have checked out in a very small window of opportunity... cluster/cman-kernel/src/cnxman-socket.h: date: 2004/08/18 16:03:43; author: pcaulfield; state: Exp; lines: +4 -2 Change AF_ number to 30 so it doesn't conflict with bluetooth. LVM2/daemons/clvmd/cnxman-socket.h: date: 2004/08/18 16:04:35; author: pcaulfield; state: Exp; lines: +19 -20 Updated file from cman.
fix verified.
Updating version to the right level in the defects. Sorry for the storm.